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: Thu, 21 Oct 2010 16:02:00 -0000	[thread overview]
Message-ID: <20101021160155.GP8337@caradoc.them.org> (raw)
In-Reply-To: <201010211550.o9LFopOt012436@d12av02.megacenter.de.ibm.com>

On Thu, Oct 21, 2010 at 05:50:51PM +0200, Ulrich Weigand wrote:
> Hmm, I'm seeing many functions marked as can't-unwind in the Ubuntu
> copy of glibc, so I was assuming this just means that for some reason
> the unwind data couldn't be generated reliably enough to allow run-time
> unwinding.  However, for debugging purposes we still want to attempt to
> show a backtrace, so I'm falling back to prologue parsing ...

Oh, right - can't unwind can be generated by the compiler, or by the
linker.  It should cover all non-fexceptions code with can't-unwind
markers.

> Note the large gap between 0x15890 and 0x25a50, which contains many
> functions, including "raise", for which the "pop {r7, r14}" instruction
> certainly isn't correct.  This caused test suite failures before I
> added the check above.
> 
> I understood the ARM standard to say that this was expected, because
> for C or assembly routines, presence of an unwind entry is optional.
> Is this not the case?

No, this is not the case.  The linker is supposed to fix it up:

/* Scan .ARM.exidx tables, and create a list describing edits which should be
   made to those tables, such that:

     1. Regions without unwind data are marked with EXIDX_CANTUNWIND entries.
     2. Duplicate entries are merged together (EXIDX_CANTUNWIND, or unwind
        codes which have been inlined into the index).

   If MERGE_EXIDX_ENTRIES is false, duplicate entries are not merged.

   The edits are applied when the tables are written
   (in elf32_arm_write_section).
*/

If it's not doing that, we should figure out why - it can lead to
crashes in libgcc, if the unwinder is invoked, rather than the correct
failure to unwind.

I think 2.19 didn't do this but 2.20 did.

> Ah, I didn't see the readelf code (because I was looking at an old
> checkout, I would appear).  I can add those personality routines as well
> (however, these are nowhere used in the glibc I'm looking at).

Correct, they're only used with C cleanups or C++ exception throw/catch.

-- 
Daniel Jacobowitz
CodeSourcery

  reply	other threads:[~2010-10-21 16:02 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
2010-10-21 15:51   ` Ulrich Weigand
2010-10-21 16:02     ` Daniel Jacobowitz [this message]
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=20101021160155.GP8337@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).