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

[Daniel Jacobowitz <drow at false dot org>]

On Tue, May 16, 2006 at 11:37:35PM +0200, Mark Kettenis wrote:
> So there are several conventions, and these make sense for a specific
> ISA or perhaps even a specific OS.

So... would you be happier if I set a gdbarch flag to control this?

I still think this is the wrong choice, and I would prefer not to do it
without opinions from a few of GDB's other maintainers, but a
compromise is better than nothing at all.

It's this statement in particular that I am disagreeing with:

> But the zero PC is *not* universal.  Therefore it should be treated
> the same as the non-zero garbage PC.

Not every system uses it, but no one overloads it to mean anything else
during correct operation and it is unambiguous.  I think that does make
it universal.  And you can not draw clear target lines on where it is
and is not used; for instance, I think at least one Linux kernel
debugging stub ends backtraces this way.  That might not be current
information; we made up a GDB convention for dwarf2 unwind terminators
and I've been trying to persuade the kernel developers to use it.

But even ignoring the issues of non-free operating systems (which I
have a different opinion on supporting, as you know), I think that
adapting existing runtimes to the debugger is putting the cart before
the horse, and free operating systems can use this convention too,
and there's a lot of them out there.

By the way, if you go ahead and remove that %ebp check, you're going to
introduce exactly this problem for current glibc on IA-32; suddenly
you'll get a bogus frame below thread_start after clone in every
thread.

> And this is exactly the case where I think the jagged end of the
> backtrace is important.  It indicates that GDB lost track somewhere
> and that the backtrace can't be trusted.

I find that the backtrace stopping at a random function is clear
enough, personally.

> I cannot imagine that a single extra frame to be a serious annoyance.
> I can see that the extra frame looses its signalling function on
> systems where it's seen a lot in cases where the stack actually ends
> that way.

For you, or for me, it is not a serious annoyance.  For users a lot
further out from the system, on top of an IDE and a development
environment, it is confusing.  For the folks who have to document those
IDEs and answer customer support questions about them when their
customers get confused, it becomes a real problem.  It's something ugly
and incorrect on their backtrace window that needs an apologetic
paragraph in the manual.  That's my benchmark for cosmetic bugs that
are worth fixing; if I was answering "why is it that way" and the best
reason I could give would be an apology, then it needs to be fixed.

That's where the lion's share of GDB use is coming to be - on top of
GUIs like KDevelop and Eclipse and probably a dozen others, for users
with less low-level experience.

-- 
Daniel Jacobowitz
CodeSourcery