|
From: Yao Qi <qiy...@cn...> - 2005-11-03 11:12:50
|
Hi, all I am thinking of how to map IRStmt to guest original instruction in valgrind tool. I find that there are some funtions relative to this purpose in include/pub_tool_debuginfo.h and include/pub_tool_execontext.h. I could only get address and length of every original instruction per IRStmt, but how could I get the content of guest instructions? I am not sure that there is such valgrind interface to tools. Am I missing something? Any comments are highly appreciated! Thanks in advance! -- Regards, Yao Yao Qi |
|
From: Tom H. <to...@co...> - 2005-11-03 11:56:02
|
In message <436...@cn...>
Yao Qi <qiy...@cn...> wrote:
> I am thinking of how to map IRStmt to guest original instruction in
> valgrind tool. I find that there are some funtions relative to this
> purpose in include/pub_tool_debuginfo.h and
> include/pub_tool_execontext.h. I could only get address and length of
> every original instruction per IRStmt, but how could I get the content
> of guest instructions?
Well if you've got the address and the length then just read it
from that address!
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Yao Qi <qiy...@cn...> - 2005-11-04 11:57:03
|
Tom Hughes wrote: > In message <436...@cn...> > Yao Qi <qiy...@cn...> wrote: > > >>I am thinking of how to map IRStmt to guest original instruction in >>valgrind tool. I find that there are some funtions relative to this >>purpose in include/pub_tool_debuginfo.h and >>include/pub_tool_execontext.h. I could only get address and length of >>every original instruction per IRStmt, but how could I get the content >>of guest instructions? > > > Well if you've got the address and the length then just read it > from that address! I have considered this solution previously, and it is an effective way to read every guest instruction in '.text' section from the client. However, it will break the integrity and encapsulation of the CLIENT--CORE--TOOL orgnization of valgrind. All the machine instructions of CLIENT are translated to an intermediate representation and optimized by CORE, and TOOL get all the information of CLIENT from CORE, so now if My tool read machine instruction directly from CLIENT bypass CORE, it would not be a best solution to this problem. The coregrind/m_debuginfo/symtab.c is a good example that TOOL get all the information from CORE instead of from CLIENT directly. Maybe, I did not describe my ideas clearly, and what I want to say is, 1 Is there any API to get the original instruction? 2 If no such API in valgrind, do you think it is necessary to implement such API in valgrind? And can someone show me where should I start to investigate it? Maybe, VG_(describe_IP)(Addr eip, Char* buf, Int n_buf) could do this, but it seems that the SegInfo do not save enought information about '.text' segment, so I am not sure that the CORE should be enhaunced to support TOOL's feature of mapping IRStmt to original instruction. I would be grateful if someone could take some time out to answer these. Thanks in advance! -- Regards, Yao Yao Qi |
|
From: Tom H. <to...@co...> - 2005-11-04 12:04:22
|
In message <436...@cn...>
Yao Qi <qiy...@cn...> wrote:
> Tom Hughes wrote:
>> In message <436...@cn...>
>> Yao Qi <qiy...@cn...> wrote:
>>
>>>I am thinking of how to map IRStmt to guest original instruction in
>>>valgrind tool. I find that there are some funtions relative to this
>>>purpose in include/pub_tool_debuginfo.h and
>>>include/pub_tool_execontext.h. I could only get address and length of
>>>every original instruction per IRStmt, but how could I get the content
>>>of guest instructions?
>> Well if you've got the address and the length then just read it
>> from that address!
>
> I have considered this solution previously, and it is an effective way to
> read every guest instruction in '.text' section from the client. However,
> it will break the integrity and encapsulation of the CLIENT--CORE--TOOL
> orgnization of valgrind.
There has never been any prohibition on tools reading areas of the
client memory - there was a prohibition on clients reading core and
tool memory but even that is now gone although we certainly wouldn't
want to encourage it.
> All the machine instructions of CLIENT are translated to an intermediate
> representation and optimized by CORE, and TOOL get all the information
> of CLIENT from CORE, so now if My tool read machine instruction directly
> from CLIENT bypass CORE, it would not be a best solution to this problem.
> The coregrind/m_debuginfo/symtab.c is a good example that TOOL get all the
> information from CORE instead of from CLIENT directly.
Because decoding the symbol table is a complex operation that the
core already needs to do so it makes sense to expose it to the tools
for them to use.
> Maybe, I did not describe my ideas clearly, and what I want to say is,
>
> 1 Is there any API to get the original instruction?
No. Unless you count VG_(memcpy) that is ;-)
> 2 If no such API in valgrind, do you think it is necessary to implement
> such API in valgrind? And can someone show me where should I start to
> investigate it?
I still don't understand the point, but here is an implementation
of such an API if you want it:
void VG_(get_instruction)(Addr addr, Int length, UChar *buf)
{
VG_(memcpy)(buf, addr, length);
}
> Maybe, VG_(describe_IP)(Addr eip, Char* buf, Int n_buf)
> could do this, but it seems that the SegInfo do not save enought
> information about '.text' segment, so I am not sure that the CORE should
> be enhaunced to support TOOL's feature of mapping IRStmt to original
> instruction.
What sort of information about the test segment do you think is
needed? If you have the address of the instruction and it's length
then what else do you need?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Josef W. <Jos...@gm...> - 2005-11-04 12:15:30
|
On Friday 04 November 2005 12:56, Yao Qi wrote: > > Well if you've got the address and the length then just read it > > from that address! > > I have considered this solution previously, and it is an effective way to > read every guest instruction in '.text' section from the client. However, > it will break the integrity and encapsulation of the CLIENT--CORE--TOOL > orgnization of valgrind. That reasoning is quite academic and not really helpful. If you can read from client memory yourself, what is the purpose of providing a function char[] VG_(please_core_read_this_memory_for_me)(void* addr, int size) ? It would be better if you can describe what you want to achieve. Do you want to pass the guest instructions to some other tool? Or are you only interested in analysing the guest instruction yourself? Whatever the tool would do with the pure guest instruction, it most probably would make the tool architecture dependent, which better should be avoided (maintenance for each architecuture needed etc.) > Maybe, VG_(describe_IP)(Addr eip, Char* buf, Int n_buf) Your function name suggests that you want to have a description of the guest instruction, and not the guest instruction itself. Why not use the description that VEX provides about the guest instruction (e.g. type of command, number of operands, type of operands and so on). If you think that some description is missing it would be better to enhance VEX to provide it. Josef |
|
From: Yao Qi <qiy...@cn...> - 2005-11-06 10:18:46
|
Josef Weidendorfer wrote: > On Friday 04 November 2005 12:56, Yao Qi wrote: > > > > That reasoning is quite academic and not really helpful. > If you can read from client memory yourself, what is the purpose of > providing a function > char[] VG_(please_core_read_this_memory_for_me)(void* addr, int size) > ? Yes, this is what I want to do, and VG_(get_instruction) and VG_(memcpy) in Tom's suggestions may be applicable for me. > > It would be better if you can describe what you want to achieve. > Do you want to pass the guest instructions to some other tool? Or are > you only interested in analysing the guest instruction yourself? Yes, sorry for unclear description. What I want to do is to get every actual executed guest instruction *itself*, and trace them, if possible. I divide this functionality into two parts, just like "front end" and "back end". The "front end" is architecture independent, that just get the content and length of every guest instruction, and "back end" translate them into ASM language, which is architecture specific and more readable. Now, I could get the content of guest instruction with libbfd support, but I do not think it is a 'smart' way to achieve this objective, so I want to get every guest instruction with internal support of valgrind CORE. > Whatever the tool would do with the pure guest instruction, it most > probably would make the tool architecture dependent, which better > should be avoided (maintenance for each architecuture needed etc.) > > >>Maybe, VG_(describe_IP)(Addr eip, Char* buf, Int n_buf) > > > Your function name suggests that you want to have a description of > the guest instruction, and not the guest instruction itself. Why > not use the description that VEX provides about the guest instruction > (e.g. type of command, number of operands, type of operands and so on). > If you think that some description is missing it would be better > to enhance VEX to provide it. Yes, you are right. Thanks for your kind help. It is a great pity my unclear description. Really sorry for the trouble it brought. Now, It seems that I am not on a right track of considering VG_(describe_IP) improvement to add guest instruction in Char* buf. Your words takes me tumble to it and bring me out of a week's puzzle. > > Josef > > -- Regards, Yao Yao Qi |
|
From: Julian S. <js...@ac...> - 2005-11-04 12:52:22
|
> 1 Is there any API to get the original instruction? > 2 If no such API in valgrind, do you think it is necessary to implement > such API in valgrind? And can someone show me where should I start to > investigate it? Why do you want to read the original instruction? What will you do with this information? J |