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

[Jim Blandy <jimb at codesourcery dot com>]

PAUL GILLIAM <pgilliam@us.ibm.com> writes:
> On Thu, 2006-05-18 at 09:53 -0700, Jim Blandy wrote:
>> Andrew STUBBS <andrew.stubbs@st.com> writes:
>> > Jim Blandy wrote:
>> >> For the record, at the top of this thread I said I thought it was
>> >> fine, too.  I've run into these often enough due to deliberate
>> >> attempts by runtimes to terminate the stack that I think it outweighs
>> >> the (minor, to my mind) value of seeing a 0x00000000 frame that
>> >> indicates an actual error.
>> >> GDB should be honest with the user about what it finds, but I don't
>> >> think we can be a multi-platform debugger and be that picky about
>> >> confining each bit of logic to exactly the platforms that promise to
>> >> uphold it.
>> >
>> > How about adding a command:
>> >
>> > set backtrace terminate-on-zero-pc on|off
>> >
>> > and let the user decide. Set it to 'on' by default on the principle
>> > that, if they aren't aware of the possibility, users don't want to see
>> > zero frames they don't understand.
>> >
>> > Just a thought.
>> 
>> Well, that would lift the burden of the decision from our shoulders
>> (that is, GDB developers', not restricted to the folks here) to the
>> users'.  I think we're probably in a better position to make it.
>
> No, that lifts the burden of deciding for *all* users from our
> shoulders, allowing those users who understand the issues to override
> our decision.
>
> On the other hand, it would add one more user tweek that most users
> would not understand or care about.
>
> It's a hard call.
>
> I'd vote for the new command and classify it as obscure.

Okay --- I should be less equivocal.  It is a bad idea to add this
command, obscure or otherwise.  Engineers do this all the time when
they're having difficulty settling on a solution: they figure, hey,
let's let the users decide!  It's presented as "giving the users more
control".  Nobody wants to argue with that: every day we run into
something we wish we could tweak.  Today I wished I could control the
'From' address vixie cron uses in its mail messages.  But it's a
mistake to treat this as an indication of the general desireability of
more switches and knobs.  And half the time the knobs are just
workarounds for some other problem --- for example, I think the real
problem with my cron is that outgoing mail on my machine is
misconfigured.

Nobody has written us saying they want to choose whether GDB treats a
zero return address as indicating the end of the stack.  Rather, many
users have written us complaining that GDB displays extra frames at
the end of well-formed, non-corrupt stacks.  And over the course of
the what seems like dozens of embedded GDB ports I've debugged since
1997, I've come across the same behavior many times myself.

The only reason presented in this thread for displaying those frames
at all is that it can be an indication of a bug in GDB.  This is based
on the (sound) general argument that GDB should be picky about the
state it examines, and report anomalies.  But that heuristic just
doesn't make sense when the particular "anomaly" at hand is, in fact,
a valid and deliberate end-of-stack indicator on many systems.