|
From: Alex B. <ker...@be...> - 2005-11-02 12:25:25
|
Hi, I seem to of tripped up an unimplemented bit of the amd64 virtual machine: vex amd64->IR: 0x4 unhandled instruction bytes: 0x67 0x8B 0x8 0x8B ==24865== ==24865== Process terminating with default action of signal 4 (SIGILL): dumping core ==24865== Illegal opcode at address 0x118F749644 ==24865== at 0x118F749644: ??? <snip> Attaching to program: /proc/24870/fd/1015, process 24870 0x000000118f749644 in ?? () (gdb) x/i $pc 0x118f749644: addr32 mov (%eax),%ecx I tried the latest SVN build which didn't seem to of changed much in the vex amd64->IR code unfortunately it doesn't even get this far failing to mmap memory. -- Alex, homepage: http://www.bennee.com/~alex/ "To vacillate or not to vacillate, that is the question ... or is it?" |
|
From: Tom H. <to...@co...> - 2005-11-02 12:43:53
|
In message <113...@ok...>
Alex Bennee <ker...@be...> wrote:
> I seem to of tripped up an unimplemented bit of the amd64 virtual
> machine:
>
> vex amd64->IR: 0x4 unhandled instruction bytes: 0x67 0x8B 0x8 0x8B
> ==24865==
> ==24865== Process terminating with default action of signal 4 (SIGILL):
> dumping core
> ==24865== Illegal opcode at address 0x118F749644
> ==24865== at 0x118F749644: ???
> <snip>
> Attaching to program: /proc/24870/fd/1015, process 24870
> 0x000000118f749644 in ?? ()
> (gdb) x/i $pc
> 0x118f749644: addr32 mov (%eax),%ecx
That's an address size override prefix which doesn't seem to be
supported at the moment - can you raise a bug for this please.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-11-02 13:26:18
|
> > vex amd64->IR: 0x4 unhandled instruction bytes: 0x67 0x8B 0x8 0x8B > > 0x118f749644: addr32 mov (%eax),%ecx > > That's an address size override prefix which doesn't seem to be > supported at the moment - can you raise a bug for this please. I've never seen such a request from any code generated by the GNU tools. What should the override do? Does it just mean the effective address should be anded with 2^32-1 once computed, or something more involved? J |
|
From: Alex B. <ker...@be...> - 2005-11-02 14:38:45
|
On Wed, 2005-11-02 at 13:28 +0000, Julian Seward wrote: > > > vex amd64->IR: 0x4 unhandled instruction bytes: 0x67 0x8B 0x8 0x8B > > > 0x118f749644: addr32 mov (%eax),%ecx > > > > That's an address size override prefix which doesn't seem to be > > supported at the moment - can you raise a bug for this please. > > I've never seen such a request from any code generated by the GNU tools. In this case its handwritten inline assembly. Although I have seen instructions generated like this by some JIT's. > What should the override do? Does it just mean the effective address > should be anded with 2^32-1 once computed, or something more involved? Pretty much. It just ignores the top 32 bits of the 64 bit result. Do you still want me to raise a bug for this one? > J > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users -- Alex, homepage: http://www.bennee.com/~alex/ You need no longer worry about the future. This time tomorrow you'll be dead. |
|
From: Tom H. <to...@co...> - 2005-11-02 13:52:43
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
>> > vex amd64->IR: 0x4 unhandled instruction bytes: 0x67 0x8B 0x8 0x8B
>> > 0x118f749644: addr32 mov (%eax),%ecx
>>
>> That's an address size override prefix which doesn't seem to be
>> supported at the moment - can you raise a bug for this please.
>
> I've never seen such a request from any code generated by the GNU tools.
>
> What should the override do? Does it just mean the effective address
> should be anded with 2^32-1 once computed, or something more involved?
It means only 32 bits are loaded from the computed address not 64. At
least that was my reading of the AMD doco.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-11-02 14:47:49
|
In message <yek...@de...>
Tom Hughes <to...@co...> wrote:
> In message <200...@ac...>
> Julian Seward <js...@ac...> wrote:
>
>>> > vex amd64->IR: 0x4 unhandled instruction bytes: 0x67 0x8B 0x8 0x8B
>>> > 0x118f749644: addr32 mov (%eax),%ecx
>>>
>>> That's an address size override prefix which doesn't seem to be
>>> supported at the moment - can you raise a bug for this please.
>>
>> I've never seen such a request from any code generated by the GNU tools.
>>
>> What should the override do? Does it just mean the effective address
>> should be anded with 2^32-1 once computed, or something more involved?
>
> It means only 32 bits are loaded from the computed address not 64. At
> least that was my reading of the AMD doco.
I've reread it now and I think you're right - it is the operand size
prefix that changes the size of the load. I'm not quite sure why you
would ever want to truncate addresses like that though - it seems a
rather odd thing to do.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|