From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5920 invoked by alias); 26 Feb 2006 20:23:18 -0000 Received: (qmail 5912 invoked by uid 22791); 26 Feb 2006 20:23:17 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sun, 26 Feb 2006 20:23:16 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FDSQB-0005mg-TD; Sun, 26 Feb 2006 15:23:12 -0500 Date: Sun, 26 Feb 2006 22:44:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: fnf@specifix.com, gdb-patches@sourceware.org Subject: Re: [PATCH] Recognize and skip interpreter_p initialization in selftest.exp Message-ID: <20060226202311.GA21625@nevyn.them.org> Mail-Followup-To: Mark Kettenis , fnf@specifix.com, gdb-patches@sourceware.org References: <200602261335.28612.fnf@specifix.com> <20060226184004.GA19823@nevyn.them.org> <200602261411.48296.fnf@specifix.com> <200602261937.k1QJbtti031456@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200602261937.k1QJbtti031456@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00487.txt.bz2 On Sun, Feb 26, 2006 at 08:37:55PM +0100, Mark Kettenis wrote: > > From: Fred Fish > > Date: Sun, 26 Feb 2006 14:11:48 -0500 > > > > On Sunday 26 February 2006 13:40, Daniel Jacobowitz wrote: > > > happen? Could you please verify a couple of things for me: that we are > > > reasonably close to the beginning of the function, that the prologue > > > skipper hasn't gone too far, and that the instruction being executed > > > has actually got some relationship to line 241. > > > > I'm not very familiar with x86 assembly so I'm probably not the best one > > to look closely at the code generated for captured_main. > > The mov $0x1,%edi is probably initializing a local variable to 1. It > is very unlikely that this instruction is part of line 241; it's much > more likely this is line 186 or 189. I'd say, that GCC is generating > bogus line number information or GDB is interpreting that line number > information uncorrectly. Either way, your "fix" is probably papering > over a real bug. Yes - though I'm not sure yet if it's GCC's or GDB's. I get the same thing on amd64 with GCC 4.0 and -O2, so I'll take a look. Actually, I also get something somewhat annoying: 0x43f000 : push %r15 0x43f002 : xor %r15d,%r15d 0x43f005 : push %r14 0x43f007 : push %r13 0x43f009 : push %r12 0x43f00b : mov $0x1,%r12d 0x43f011 : push %rbp 0x43f012 : mov $0x1,%ebp 0x43f017 : push %rbx 0x43f018 : mov %rdi,%rbx "break captured_main" stops on 0x43f000. >From the object file, where captured_main starts at 0x70: Special opcode 173: advance Address by 12 to 0x70 and Line by 0 to 120 Advance Line by 121 to 241 Special opcode 33: advance Address by 2 to 0x72 and Line by 0 to 241 Advance Line by -121 to 120 Special opcode 47: advance Address by 3 to 0x75 and Line by 0 to 120 Advance Line by 121 to 241 It's definitely a GCC "issue", I'm not sure if "bug" applies. The sched2 pass moves an insn from line 241 all the way up. But that seems to have happened because ndir == 0 and cmdsize == 1 have gotten associated with that line. It appears to be an artifact of SSA; the loop is right after line 241, and the line number is being lost when the initialization of ndir is propogated into the phi node. Then it gets scheduled way up high again, which is unrelated. This is now GCC PR 26475. Since it's been analyzed, and to prevent cascading failures, maybe we should go with Fred's patch plus a reference to the GCC PR? -- Daniel Jacobowitz CodeSourcery