This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] Move the frame zero PC check earlier
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