public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andrew Haley <aph@redhat.com>
To: Paul Brook <paul@codesourcery.com>
Cc: gcc@gcc.gnu.org, Daniel Jacobowitz <drow@false.org>,
	       Ken Werner <ken.werner@linaro.org>,
	ramana.radhakrishnan@arm.com,        richard.earnshaw@arm.com
Subject: Re: ARM Linux EABI: unwinding through a segfault handler
Date: Thu, 27 Oct 2011 09:06:00 -0000	[thread overview]
Message-ID: <4EA918D0.3000009@redhat.com> (raw)
In-Reply-To: <201110270215.09012.paul@codesourcery.com>

On 10/27/2011 02:15 AM, Paul Brook wrote:
>>>> So, suggestions welcome.  Is there a nice way to detect a signal frame?
> 
> That just makes me ask why are you're trying to detect a signal frame in the 
> first place?

Because I need backtrace() to work when called from a signal handler.

>>> Libunwind also reads the IP to detect signal frames on ARM Linux:
>>> http://git.savannah.gnu.org/gitweb/?p=libunwind.git;a=blob;f=src/arm/Gis_
>>> signal_frame.c;hb=HEAD
>>>
>>> I'd also be interested if there are better approaches to detect them. :)
>>
>> There aren't better ways - this is pretty much the standard for
>> on-stack signal frames :-)
>>
>> I thought we used a handler in GLIBC that was properly annotated,
>> nowadays, but I might be mistaken.
> 
> We do, but the annotation is fairly approximate.
> 
> Short story is that the standard EABI unwinding opcodes can't describe a 
> signal frame accurately.  Especially if we don't know (when building glibc) 
> whether the application will be using VFP.
> 
> The good news is that The EABI unwinding tables delegate all interesting 
> behavior to the personality routine (c.f. DWARF unwinding where the frame 
> description is parsed by libunwind).  In order to accurately unwind signal 
> frames you need to have the sa_restorer functions reference a custom 
> personality routine that does the unwinding.
> 
> If something is specifying a non-default sa_restorer, then you loose.
> Don't Do That :-)
> 
> While Richard is correct that the ARM EABI only requires unwinding information 
> at call sites, in practice as long as you use and accept the limitations 
> imposed by -fnon-call-exceptions, and ignore stack overflows, it should be 
> sufficient. 

Sure, but without the fix I provided it doesn't work.  The problem is
that the return address points to the faulting instruction, not the
following instruction.  In the generic unwinder code, the boolean
ip_before_insn is set to cope with this.  The ARM unwinder does not
set this, so the backtrace does not work.

All you have to do to make it work is set ip_before_insn when a signal
frame is detected.  The patch I provided, which unfinished is quite
robust, and works in the same way as the libunwind code that parses
the EABI information.

Andrew.

  reply	other threads:[~2011-10-27  8:40 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-25 12:26 Andrew Haley
2011-08-25 16:57 ` David Daney
2011-08-25 17:01   ` Andrew Haley
2011-08-29 15:19 ` Ken Werner
2011-08-29 17:14   ` Daniel Jacobowitz
2011-08-30  9:11     ` Andrew Haley
2011-08-30 15:28     ` Joseph S. Myers
2011-10-27  8:33     ` Paul Brook
2011-10-27  9:06       ` Andrew Haley [this message]
2011-10-27 12:54         ` Paul Brook
2011-10-27 12:55           ` Andrew Haley
2011-10-27 13:25             ` Paul Brook
2015-02-03 22:41               ` mads_bn
2015-09-18 15:37                 ` Matthijs van Duin
2015-10-03 20:41                   ` Matthijs van Duin
2015-10-04  8:05                     ` Andrew Haley
2015-10-04 12:09                       ` Matthijs van Duin
2015-10-05 15:24                         ` Ian Lance Taylor
2015-02-03 22:42               ` mads_bn
2014-08-01 12:25 ` prafullakota
2015-10-04  8:50 SV: " mads_bn
2015-10-04 13:09 ` Matthijs van Duin

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=4EA918D0.3000009@redhat.com \
    --to=aph@redhat.com \
    --cc=drow@false.org \
    --cc=gcc@gcc.gnu.org \
    --cc=ken.werner@linaro.org \
    --cc=paul@codesourcery.com \
    --cc=ramana.radhakrishnan@arm.com \
    --cc=richard.earnshaw@arm.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).