From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3424 invoked by alias); 14 Jan 2003 06:50:30 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 3415 invoked from network); 14 Jan 2003 06:50:25 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 14 Jan 2003 06:50:25 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18YMmd-0007xV-00 for ; Tue, 14 Jan 2003 02:50:56 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18YKuO-0003Qk-00 for ; Tue, 14 Jan 2003 01:50:48 -0500 Date: Tue, 14 Jan 2003 06:50:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Re: A testsuite update, for the curious Message-ID: <20030114065048.GA12936@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com References: <20030114050519.GA5421@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030114050519.GA5421@nevyn.them.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00224.txt.bz2 On Tue, Jan 14, 2003 at 12:05:19AM -0500, Daniel Jacobowitz wrote: > One FAIL from gdb.gdb/complaints.exp. This has been around for a little > while; I haven't looked at it yet. Oh, it's a bug I see very frequently. > Given: > 93 static int > 94 captured_command_loop (void *data) > 95 { > 96 if (command_loop_hook == NULL) > 97 command_loop (); > and GCC 2.95.3 + optimization, we place the breakpoint after the conditional > branch, and lose. I'm not entirely sure why this happens but it seems that > it may be a bad interaction with my previous workaround for bad stabs from > this compiler (but it's not that simple, since I first remember seeing it > two years or so before I implemented the workaround). I'll dig through my > notes for the previous patch and see if I can manage to accomodate both > forms of bugginess. If not, I'm not going to sweat this one too much, but > I'd like to. I don't think it's reliably fixable. Here's the problem. With all compilers, we assume (correctly it seems) that: - the beginning of the function is before the prologue (duh) - the second line note is after the prologue With most working compilers: - the first line note is at the beginning of the function, before the prologue - the second line note is immediately after the prologue, a good place to stop With GCC 2.95.3: - the first line note is somewhere in the middle of the prologue, generally between stack frame adjustment and storing local variables into their frame slots (if any, so sometimes it's at the end of the prologue) - the second line note may mark the end of the prologue, but with optimization if the first two line notes were in the same place (i.e. no stack temps being saved after stack frame adjustment) then one of them will be deleted. Then the second line note marks an arbitrary line in the function. There can be branches between the first two line notes :( So the debug info workaround in place for this compiler can not be extended to reliably cover this problem. Since we call the prologue skipper from find_pc_start_sal anyway, it would be nice for it to return a flag indicating "no, you really can not extend this address to the next line boundary".... since obviously this comment: - Compilers usually emit line number info that marks the prologue as its own "source line". So the ending address of that "line" is the end of the prologue. If available, this is the most reliable method. has a certain flaw. We don't always call the prologue skipper from in_prologue (), though. Why does it use a different search order than find_function_start_sal ()? Is calling the prologue skipper every time acceptable? Should we just write off this as lost? I like the surety of having the architecture specific code have a chance to say "no, this is a branch, don't think it's in the prologue!" since this bug does repeatedly bite me when I'm debugging optimized code. On the other hand, if we ignore it a little longer it'll go away. GCC 3.x is fixed. So if the consensus is that it's too much effort to bother, I can handle that and just crawl back into my hole. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer