Re: A testsuite update, for the curious

[Daniel Jacobowitz <drow@mvista.com>]

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