Re: [RFC] Move the frame zero PC check earlier

[Andrew STUBBS <andrew dot stubbs at st dot com>]

Mark Kettenis wrote:
> And this is exactly the reason why things are done the way they are
> done.  People should accept that the unwinder can fail, and we should
> provide a way to indicate this.  There are many ways in which an
> unwinder can fail and they're not always detectable.  One very
> important scemario is where your program is thrashing the stack,
> overwriting the return address.  We absulutely need to provide the
> user some indication that something is wrong.  Currently this is the
> extra frame we're printing.

Except that I get this when there is nothing wrong. I.e. It is crying wolf.

The problem I have seems to be that the function that launches a thread 
has dwarf debug information and GDB can't accept that the first function 
on the stack can have this. It unwinds all through the stack till it 
reaches the end of the dwarf functions and then tries the machine 
specific unwinder. This MUST return at least one frame, even though it 
knows there isn't one. If it returns NULL, like the dwarf unwinder does, 
 then you get an internal error message, so it returns a null frame ID 
and causes a null frame in the display.

Daniel's patch fixes my problem.

> Our goal shouldn't be nicer looking backtraces.  It should be
> providing the user with all information needed to fix bugs in their
> programs.  Your patch is removing such a bit of information, and
> therefore unacceptable to me.  Sorry :(.

It shouldn't be saying there are problems where there are none.

Andrew