|
From: Jim C. <cl...@cc...> - 2008-06-04 01:34:50
|
Hi, I'm encountering a case where I'm getting an unexpected (to me) IR generation from VEX. When VEX generates IR from the following function: Dump of assembler code for function main: 0x00001fce <main+0>: push %ebp 0x00001fcf <main+1>: mov %esp,%ebp 0x00001fd1 <main+3>: sub $0x28,%esp 0x00001fd4 <main+6>: movl $0x0,-0x10(%ebp) 0x00001fdb <main+13>: movl $0x40,(%esp) 0x00001fe2 <main+20>: call 0x3005 <dyld_stub_malloc> 0x00001fe7 <main+25>: mov %eax,-0x10(%ebp) 0x00001fea <main+28>: lea -0x10(%ebp),%eax 0x00001fed <main+31>: mov %eax,-0xc(%ebp) 0x00001ff0 <main+34>: mov -0xc(%ebp),%eax 0x00001ff3 <main+37>: inc %eax 0x00001ff4 <main+38>: movb $0x1,(%eax) 0x00001ff7 <main+41>: mov $0x0,%eax 0x00001ffc <main+46>: leave 0x00001ffd <main+47>: ret End of assembler dump. The movb instruction at main+38 is transformed into STle(t21) = 0x1:I8, which looks good except that the type of the destination is Ity_I32 not Ity_I8 like I would expect. Is Ity_I32 the correct size for t21? If it's not a possible fix might be to change disAMode_copy2tmp to generate a new temporary that the same size as it's argument rather than just a new Ity_I32. Thanks, Jim |
>>>>> "JC" == Jim Clause <cl...@cc...> writes:
JC> Hi,
JC> I'm encountering a case where I'm getting an unexpected (to me) IR
JC> generation from VEX. When VEX generates IR from the following
JC> function:
JC> Dump of assembler code for function main:
....
JC> 0x00001ff4 <main+38>: movb $0x1,(%eax)
JC> The movb instruction at main+38 is transformed into STle(t21) =
JC> 0x1:I8, which looks good except that the type of the destination
JC> is Ity_I32 not Ity_I8 like I would expect. Is Ity_I32 the correct
JC> size for t21?
In full, it's translated into something like:
------ IMark(0x804839A, 3) ------
PUT(60) = 0x804839A:I32
t21 = GET:I32(0)
STle(t21) = 0x1:I8
STle represents a store to memory, and the argument in parentheses is
the address of the location to store. So I think that it's right for
it to be word-sized (32 bits for an x86), not the size of the data
you're storing. In the full example, you can see that the value of t21
is GET:I32(0), which is the way the IR refers to %eax in the guest
state.
JC> If it's not a possible fix might be to change disAMode_copy2tmp to
JC> generate a new temporary that the same size as it's argument
JC> rather than just a new Ity_I32.
I think the argument to disAMode_copy2tmp for the x86 is already
always an I32 expression, as suggested by the parameter name "addr32".
If it were anything else, it would be an IR type error to assign it to
an I32 temporary: you always have to be explicit about size
conversions in IR.
Hope this helps,
-- Stephen
|
|
From: Julian S. <js...@ac...> - 2008-06-04 22:48:29
|
On Wednesday 04 June 2008 04:37, Stephen McCamant wrote: > ------ IMark(0x804839A, 3) ------ > PUT(60) = 0x804839A:I32 > t21 = GET:I32(0) > STle(t21) = 0x1:I8 > > STle represents a store to memory, and the argument in parentheses is > the address of the location to store. So I think that it's right for > it to be word-sized (32 bits for an x86), not the size of the data > you're storing. Yup. t21 is the store address, so it must have type I32. 0x1:I8 is the store data; it has type I8 and so this is indeed an 8-bit store. J |