From: Michael Snyder <msnyder@vmware.com>
To: Hui Zhu <teawater@gmail.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: Bug in i386_process_record
Date: Mon, 17 Aug 2009 18:17:00 -0000 [thread overview]
Message-ID: <4A899A13.6090102@vmware.com> (raw)
In-Reply-To: <daef60380908162034u188a49e6nf0b52531a0584dc2@mail.gmail.com>
Hui Zhu wrote:
> Hi Michael,
>
> I think this is not a bug.
Have you tried running the machinestate.exp test on intel 32?
It fails! Take out the amd64 patch, and it passes! Put the
amd64 patch back in, but comment out "case 0x43", it passes!
Heh -- sorry about the exclamation points... ;-)
See below.
> In "Intel® 64 and IA-32 Architectures Software Developer’s Manual
> Volume 2A: Instruction Set Reference, A-M" INC—Increment by 1, it
> said:"In 64-bit mode, INC r16 and INC r32 are not encodable (because
> opcodes 40H
> through 47H are REX prefixes)."
> And disas of machinestate is clear:
> (gdb) disas /m register_state
> Dump of assembler code for function register_state:
> 29 {
> 0x0000000000400488 <register_state+0>: push %rbp
> 0x0000000000400489 <register_state+1>: mov %rsp,%rbp
> 0x000000000040048c <register_state+4>: push %rbx
> 0x000000000040048d <register_state+5>: sub $0x8,%rsp
>
> 30 register int a = 0;
> 0x0000000000400491 <register_state+9>: mov $0x0,%ebx
>
> 31
> 32 hide (a); /* External function to defeat optimization. */
> 0x0000000000400496 <register_state+14>: mov %ebx,%edi
> 0x0000000000400498 <register_state+16>: callq 0x400598 <hide>
>
> 33 a++; /* register_state: set breakpoint here */
> 0x000000000040049d <register_state+21>: add $0x1,%ebx
>
> 34 hide (a); /* register post-change */
> 0x00000000004004a0 <register_state+24>: mov %ebx,%edi
> 0x00000000004004a2 <register_state+26>: callq 0x400598 <hide>
>
> 35 }
> 0x00000000004004a7 <register_state+31>: add $0x8,%rsp
> 0x00000000004004ab <register_state+35>: pop %rbx
> 0x00000000004004ac <register_state+36>: leaveq
> 0x00000000004004ad <register_state+37>: retq
>
> End of assembler dump.
>
> In amd64, 0x40-0x47 will not be use to inv.
Yes, but in intel32, it is used. By the way, I used your
clever "disas /r" to discover it:
33 a++; /* register_state: set breakpoint here */
0x08048358 <register_state+24>: 43 inc %ebx
> On Mon, Aug 17, 2009 at 00:12, Hui Zhu<teawater@gmail.com> wrote:
>> case 0x67:
>> prefixes |= PREFIX_ADDR;
>> break;
>> case 0x40:
>> case 0x41:
>> case 0x42:
>> case 0x43:
>> case 0x44:
>> case 0x45:
>> case 0x46:
>> case 0x47:
>>
>> /* inv */
>> case 0x40:
>> case 0x41:
>> case 0x42:
>> case 0x43:
>> case 0x44:
>> case 0x45:
>> case 0x46:
>> case 0x47:
>>
>> Oops, I must make something wrong. I need check the spec of amd64 clear.
>>
>> Thanks,
>> Hui
>>
>> On Sun, Aug 16, 2009 at 09:08, Michael Snyder<msnyder@vmware.com> wrote:
>>> Hi Hui,
>>>
>>> This line in i386-tdep.c causes 4 failures in machinestate.exp.
>>>
>>> diff -u -p -r1.283 i386-tdep.c
>>> --- i386-tdep.c 10 Aug 2009 03:02:39 -0000 1.283
>>> +++ i386-tdep.c 16 Aug 2009 01:07:48 -0000
>>> @@ -3283,7 +3283,7 @@ i386_process_record (struct gdbarch *gdb
>>> case 0x40:
>>> case 0x41:
>>> case 0x42:
>>> - case 0x43:
>>> + // case 0x43:
>>> case 0x44:
>>> case 0x45:
>>> case 0x46:
>>>
>>> 0x43 is "inc %ebx", and this line causes it to be treated as a prefix,
>>> consuming the instruction without recording the register change.
>>>
>>> I don't want to change it myself, because I'm not sure what other
>>> side effects the change might have. Could you fix it please? ;-)
>>>
>>> Thanks,
>>> Michael
>>>
>>>
prev parent reply other threads:[~2009-08-17 18:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-16 12:45 Michael Snyder
2009-08-16 18:55 ` Hui Zhu
2009-08-17 6:36 ` Hui Zhu
2009-08-17 14:37 ` Hui Zhu
2009-08-17 18:34 ` Michael Snyder
2009-08-18 3:03 ` Hui Zhu
2009-08-18 9:11 ` Hui Zhu
2009-08-18 9:22 ` Hui Zhu
2009-08-17 18:17 ` Michael Snyder [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A899A13.6090102@vmware.com \
--to=msnyder@vmware.com \
--cc=gdb-patches@sourceware.org \
--cc=teawater@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox