This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: A testsuite update, for the curious
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: gdb at sources dot redhat dot com
- Date: Tue, 14 Jan 2003 01:50:48 -0500
- Subject: Re: A testsuite update, for the curious
- References: <20030114050519.GA5421@nevyn.them.org>
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