From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12896 invoked by alias); 23 Aug 2009 04:30:08 -0000 Received: (qmail 12880 invoked by uid 22791); 23 Aug 2009 04:30:04 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-pz0-f198.google.com (HELO mail-pz0-f198.google.com) (209.85.222.198) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 23 Aug 2009 04:29:55 +0000 Received: by pzk36 with SMTP id 36so478631pzk.12 for ; Sat, 22 Aug 2009 21:29:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.2.39 with SMTP id 39mr143795wfb.106.1251001793312; Sat, 22 Aug 2009 21:29:53 -0700 (PDT) In-Reply-To: <4A90C08A.8000107@vmware.com> References: <4A7BA1DE.6010103@vmware.com> <4A8097B4.2080709@vmware.com> <4A8A2ACD.9000208@vmware.com> <4A90B261.2030602@vmware.com> <4A90C08A.8000107@vmware.com> From: Hui Zhu Date: Sun, 23 Aug 2009 09:04:00 -0000 Message-ID: Subject: Re: Bug in i386_process_record? To: Michael Snyder Cc: gdb-patches ml Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00365.txt.bz2 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. =A0I 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: > =A0 =A0 =A0 =A0 =A0 if (ir.aflag) > =A0 =A0 =A0 =A0 =A0 =A0 { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* addr +=3D ((uint32_t) read_register (I386_= ES_REGNUM)) << 4; > */ > - =A0 =A0 =A0 =A0 =A0 =A0 =A0if (record_debug) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf_unfiltered (_("Process record ign= ores the memory > change " > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= "of instruction at address 0x%s > because " > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= "it can't get the value of the segment > " > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= "register.\n"), > + =A0 =A0 =A0 =A0 =A0 =A0 =A0if (record_debug && > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 read_register (I386_ES_REGNUM) !=3D 0) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf_unfiltered (_("Process record ign= ores value of ES " > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= "register for instruction at address > %s " > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= "because "it can't get the value of " > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= "the segment register.\n"), > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pa= ddress (gdbarch, ir.addr)); > =A0 =A0 =A0 =A0 =A0 =A0 } > =A0 =A0 =A0 =A0 =A0 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 .... Hui