Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Michael Snyder <msnyder@vmware.com>
To: Hui Zhu <teawater@gmail.com>
Cc: gdb-patches ml <gdb-patches@sourceware.org>
Subject: Re: Bug in i386_process_record?
Date: Sun, 23 Aug 2009 18:23:00 -0000	[thread overview]
Message-ID: <4A917D5F.8000401@vmware.com> (raw)
In-Reply-To: <daef60380908222129g483ed968sce36e561a0febf2f@mail.gmail.com>

Hui Zhu wrote:
> On Sun, Aug 23, 2009 at 12:07, Michael Snyder<msnyder@vmware.com> wrote:
>> Hui Zhu wrote:
>>> On Sun, Aug 23, 2009 at 11:07, Michael Snyder<msnyder@vmware.com> wrote:
>>>> Hi, please *don't* check this in -- I found a problem with it.
>>>>
>>>> Try running it with "set debug record 1" during the recording pass.
>>>>
>>>> I see a whole lot of these:
>>>>
>>>> Process record ignores the memory change of instruction at address
>>>> 0x0x587be9 because it can't get the value of the segment register.
>>>
>>> Hi Michael,
>>>
>>> Most of the string ops instruction will use segment register.
>>> But I check the some linux program that have string ops insn.  I found
>>> that in linux (maybe glibc), the value of the segment register is 0,
>>> so it will not affect anything.
>> Hmm, ok, but this is i386-tdep.c, not i386-linux-tdep.c...
>>
>>> And in linux user level, looks we don't have any good way to get the
>>> value of the segment register.
>>>
>>> So I think this patch is OK.
>> I see -- so, we don't really "ignore" the memory change at all.
>>
>> Isn't the message misleading, then?
>>
>> What about something like:
>>
>> @@ -4458,11 +4458,12 @@ reswitch:
>>           if (ir.aflag)
>>             {
>>               /* addr += ((uint32_t) read_register (I386_ES_REGNUM)) << 4;
>> */
>> -              if (record_debug)
>> -                printf_unfiltered (_("Process record ignores the memory
>> change "
>> -                                     "of instruction at address 0x%s
>> because "
>> -                                     "it can't get the value of the segment
>> "
>> -                                     "register.\n"),
>> +              if (record_debug &&
>> +                 read_register (I386_ES_REGNUM) != 0)
>> +                printf_unfiltered (_("Process record ignores value of ES "
>> +                                     "register for instruction at address
>> %s "
>> +                                     "because "it can't get the value of "
>> +                                     "the segment register.\n"),
>>                                    paddress (gdbarch, ir.addr));
>>             }
>>           if (prefixes & (PREFIX_REPZ | PREFIX_REPNZ))
>>
> 
> read_register (I386_ES_REGNUM)
> This value is not the value of ES.  This is number of TLB.  So ....

So... what?  I don't know about these things.
I'm just asking, could the message be more informative or accurate than 
it is?

The message seems to say "ignores the memory change", which to me
implies "does not record the memory change".  Yet the code seems
to imply that it *does* record the memory change, it just ignores
the ES offset.


  parent reply	other threads:[~2009-08-23 17:37 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4A7BA1DE.6010103@vmware.com>
2009-08-10  9:33 ` Hui Zhu
2009-08-10 22:12   ` Michael Snyder
2009-08-11  6:20     ` Hui Zhu
2009-08-11 18:31     ` Hui Zhu
2009-08-16 16:12       ` Hui Zhu
2009-08-18  5:35       ` Michael Snyder
2009-08-18 11:52         ` Hui Zhu
2009-08-21  3:23           ` Hui Zhu
2009-08-23  3:15             ` Michael Snyder
2009-08-23  3:33               ` Hui Zhu
2009-08-23  4:13                 ` Michael Snyder
2009-08-23  9:04                   ` Hui Zhu
2009-08-23 17:37                     ` Hui Zhu
2009-08-23 18:23                     ` Michael Snyder [this message]
2009-08-23 18:32                     ` Eli Zaretskii
2009-08-23 23:53                       ` Hui Zhu
2009-08-23 23:56                         ` Daniel Jacobowitz
2009-08-24  0:01                           ` Hui Zhu
2009-08-24  7:46                           ` Eli Zaretskii
2009-08-24  3:15                         ` Hui Zhu
2009-08-24 19:20                           ` Eli Zaretskii
2009-08-25  5:04                             ` Hui Zhu
2009-08-25 18:45                               ` Eli Zaretskii
2009-08-26  3:19                                 ` Hui Zhu
2009-08-26  3:27                                   ` Eli Zaretskii
2009-08-26  7:20                                     ` Hui Zhu
2009-08-26 17:37                                       ` Eli Zaretskii
2009-08-27  0:05                                   ` Michael Snyder
2009-08-27  0:32                                     ` Michael Snyder
2009-08-27  1:50                                       ` Hui Zhu
2009-08-27 15:35                                         ` Hui Zhu
2009-08-28  1:44                                           ` Michael Snyder
2009-08-28  2:14                                             ` Hui Zhu
2009-08-28  6:16                                               ` Michael Snyder
2009-08-28  8:46                                                 ` Hui Zhu
2009-08-30  1:12                                                   ` Michael Snyder
2009-08-27  1:44                                     ` Hui Zhu
2009-08-29  6:51                                     ` Hui Zhu
2009-08-24 20:31                         ` Eli Zaretskii
2009-08-25  6:53                           ` Hui Zhu
2009-08-23 18:24                   ` Eli Zaretskii

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=4A917D5F.8000401@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