This is the mail archive of the
mailing list for the GCC project.
Re: RFA: add debug hook to unwinder
- From: Michael Meissner <meissner at linux dot vnet dot ibm dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 14 Apr 2009 14:43:35 -0400
- Subject: Re: RFA: add debug hook to unwinder
- References: <firstname.lastname@example.org>
On Thu, Apr 09, 2009 at 05:25:50PM -0600, Tom Tromey wrote:
> This patch adds a debugging hook to the dwarf unwinder.
> The basic problem is that gdb can lose control of the inferior in the
> presence of exceptions. For example, if the user "next"s over a
> function call, but that call throws an exception which passes over the
> "next"ing frame, gdb will act as if the user typed "continue". That
> is because gdb has no way to intercept the exception as it unwinds the
> I looked at a couple of approaches to fixing this. The simplest was
> to to add a hook to the unwinder, just for gdb. So, that is what this
> patch implements.
> This patch does add a cost to all thrown exceptions. However, I judge
> this cost to be small, particularly given the existing cost of a
> I've only updated the dwarf unwinder, but I think the same treatment
> could be given to other unwinders.
> I have a corresponding gdb patch to make this all work. I will put
> that in sometime after this patch.
> I've bootstrapped and regtested this on x86-64 (compile farm). (But
> really this is pointless as the code does nothing until the debugger
> sets the new _Unwind_DebugTrigger global.)
> I did not document this because I did not see a good place for that.
Instead of adding a global int variable that is tested, another approach would
be to have a global pointer to a function that is called all of the time, and
the debugger could then change where the pointer points to. If you are worried
about the cost of an indirect function, I imagine it could test whether the
pointer is 0 or not.
This way, it would allow other ways of catching the unwind, rather than having
to use the debugger.
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA