public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
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

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