From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28888 invoked by alias); 23 Aug 2009 17:37:47 -0000 Received: (qmail 28877 invoked by uid 22791); 23 Aug 2009 17:37:46 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 23 Aug 2009 17:37:41 +0000 Received: from jupiter.vmware.com (mailhost5.vmware.com [10.16.68.131]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 6A98F5A001; Sun, 23 Aug 2009 10:37:37 -0700 (PDT) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by jupiter.vmware.com (Postfix) with ESMTP id 5DF90DC07B; Sun, 23 Aug 2009 10:37:37 -0700 (PDT) Message-ID: <4A917D5F.8000401@vmware.com> Date: Sun, 23 Aug 2009 18:23:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Hui Zhu CC: gdb-patches ml Subject: Re: Bug in i386_process_record? References: <4A7BA1DE.6010103@vmware.com> <4A8097B4.2080709@vmware.com> <4A8A2ACD.9000208@vmware.com> <4A90B261.2030602@vmware.com> <4A90C08A.8000107@vmware.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-08/txt/msg00369.txt.bz2 Hui Zhu wrote: > On Sun, Aug 23, 2009 at 12:07, Michael Snyder wrote: >> Hui Zhu wrote: >>> On Sun, Aug 23, 2009 at 11:07, Michael Snyder 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.