From: Daniel Jacobowitz <dan@codesourcery.com>
To: Ulrich Weigand <uweigand@de.ibm.com>
Cc: gdb-patches@sourceware.org, rearnsha@arm.com,
matthew.gretton-dann@arm.com
Subject: Re: [rfc/rfa] Use ARM exception tables as GDB unwinder
Date: Wed, 20 Oct 2010 13:27:00 -0000 [thread overview]
Message-ID: <20101020132657.GU8337@caradoc.them.org> (raw)
In-Reply-To: <201010200000.o9K00u7j016909@d12av02.megacenter.de.ibm.com>
Thanks for doing this!
On Wed, Oct 20, 2010 at 02:00:56AM +0200, Ulrich Weigand wrote:
> In addition, one minor change was necessary to the prologue unwinder:
> the this_id routine no longer uses get_frame_func to retrieve the
> function start address; instead, this value is stored in the cache.
> This allows the exception unwinder to provide this information from
> the exception table, instead of having to rely on symbol data.
Like Matthew, I have some concern about this; unwind regions are not
1:1 with functions. Not only will the linker combine identical
regions, but hand-written code (or, hypothetically,
-fnon-call-exceptions) can have multiple regions in a function.
But we can probably ignore the latter case; the former can be handled
by using whichever is larger, the symbol or exception region address.
> + /* See if we have an ARM exception table entry covering this address. */
> + addr_in_block = get_frame_address_in_block (this_frame);
> + entry = arm_find_exidx_entry (addr_in_block, &func_exidx);
> + if (!entry)
> + return 0;
I assume you're deliberately treating can't-unwind and no-information
the same. We use can't-unwind to mark _start, but it also shows up in
exception handling in some cases.
> + /* The ARM exception index does not mark the *end* of the function
> + covered by the entry, and some functions will not have any entry.
> + Therefore, the entry we found above may not actually be correct
> + for this PC. As a sanity check, also try to determine the function
> + covering PC via the symbol table. If this finds a function start
> + address *closer* to PC than the one found via the exception table,
> + ignore the exception record, and fall back to prologue parsing.
> +
> + (Note that if we don't find a function via the symbol table, the
> + exception table may still be wrong. But in this case, prologue
> + parsing wouldn't work anyway, so we use the exception table and
> + hope for the best.) */
> + if (find_pc_partial_function (addr_in_block, NULL, &func_symtab, NULL)
> + && func_symtab > func_exidx)
> + return 0;
This doesn't go well with the discussion above about combined
exception regions... did you encounter this problem in practice? The
linker used to have this problem, but hasn't for a while (circa
2009-05-05).
The actual unwinder looks OK to me. If you want to handle C++ code
with exceptions (or C with cleanups), you'll need to check the name of
the referenced personality routine; it is __gxx_personality_v0 (et
cetera). Readelf has a sample of that. Code which doesn't throw or
catch uses the standard personality routines, as you've implemented.
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2010-10-20 13:27 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-20 0:01 Ulrich Weigand
2010-10-20 11:14 ` Matthew Gretton-Dann
2010-10-21 15:39 ` Ulrich Weigand
2010-10-20 13:27 ` Daniel Jacobowitz [this message]
2010-10-21 15:51 ` Ulrich Weigand
2010-10-21 16:02 ` Daniel Jacobowitz
2010-10-21 18:26 ` Ulrich Weigand
2010-10-21 18:42 ` Daniel Jacobowitz
2010-10-21 20:29 ` Ulrich Weigand
2010-10-21 20:43 ` Daniel Jacobowitz
2010-12-01 16:45 ` Ulrich Weigand
2010-12-12 4:21 ` Daniel Jacobowitz
2010-12-12 12:24 ` Andreas Schwab
2011-03-09 19:11 ` Ulrich Weigand
2011-03-11 22:35 ` Daniel Jacobowitz
2011-03-19 4:25 ` Ulrich Weigand
2011-03-21 14:51 ` Daniel Jacobowitz
2011-03-21 20:06 ` Ulrich Weigand
2010-10-21 22:26 ` Ulrich Weigand
2010-10-26 13:43 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101020132657.GU8337@caradoc.them.org \
--to=dan@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=matthew.gretton-dann@arm.com \
--cc=rearnsha@arm.com \
--cc=uweigand@de.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).