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

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> From: Jim Blandy <jimb@codesourcery.com>
> Date: Thu, 18 May 2006 11:09:33 -0700
> 
> 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.

I 100% agree.  Knobs are bad.  Besides we'd be quibbling about the
default setting for that knob ;-).

> 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.

If we're sure that zero return address actually signals the end of the
stack, then indeed we should not print the extra frame.  I'm not
arguing with that.  But that's defenitely 

> 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.

No.  There are two reasons why we should print those frames, and I
consider both of them not to be an indication of a bug in GDB.

1. Because of a bug in the program you're debugging, it has
   overwritten the return address on the stack.  Currently this causes
   the extra frame to be printed signalling the user that something is
   wrong.  Daniel's patch changes this, but only if the return address
   is overwritten with zero.

2. It may be fundamentally impossible to unwind code produced by an
   optimizing compiler without additional debug info.  We can't
   consider the fact that GDB gets the return address wrong if the
   debug info is missing a bug in GDB.  Again the extra frame signals
   the user that something is wrong.

Reason #2 is exactly the example Daniel gave in the message that
started this thread.  He noticed that something was wrong and fixed
the problem by provide the necessary debug info.  Now Daniel would
probably have noticed the problem even if the extra frame had not been
there.  But it almost certainly would have taken him a bit more time,
and a less experienced user might not have noticed it.

> 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.

Many systems, but certainly not all systems.  At least i386, amd64,
sparc and sparc64 don't use this convention.  I'm sure there are
others.  From the traffic on the lists it sure seems as if 90% of the
people are using gdb to remotely debug an ARM target from a Windows
system, but there must be some sort of selection effect going on here,
since more than 10% of our users must be using GDB on i386/amd64
GNU/Linux systems.

Mark