ARM Linux EABI: unwinding through a segfault handler

ARM Linux EABI: unwinding through a segfault handler

[Andrew Haley]

[-- Attachment #1: Type: text/plain, Size: 3455 bytes --]

Throwing an exception through a segfault handler doesn't always work
on ARM: the attached example fails on current gcc trunk.

panda-9:~ $ g++ segv.cc -fnon-call-exceptions -g
panda-9:~ $ ./a.out
terminate called after throwing an instance of 'FoobarException*'
Aborted

The bug is that _Unwind_GetIPInfo doesn't correctly set ip_before_insn.
Instead, it always sets it to zero; it should be set to 1 if this
is a frame created by a signal handler:


#define _Unwind_GetIPInfo(context, ip_before_insn) \
  (*ip_before_insn = 0, _Unwind_GetGR (context, 15) & ~(_Unwind_Word)1)


Fixing this on ARM is hard because signal frames aren't specially
marked as they are on systems that use DWARF unwinder data.  I have
a patch that works on systems where the signal restorer is exactly

        mov     r7, $SYS_rt_sigreturn
        swi     0x0

It works as a proof of concept, but it's fugly.

So, suggestions welcome.  Is there a nice way to detect a signal frame?

Andrew.


2011-08-25  Andrew Haley  <aph@redhat.com>

	* config/arm/unwind-arm.h (_Unwind_IsSignalFrame): New.
	(_Unwind_GetIPInfo): Use _Unwind_IsSignalFrame.
	* config/arm/unwind-arm.c (UCB_SIGNAL_FRAME): New def.
	(get_eit_entry): Update UCB_SIGNAL_FRAME.
	(_Unwind_IsSignalFrame): New function.

Index: config/arm/unwind-arm.c
===================================================================
--- config/arm/unwind-arm.c     (revision 178028)
+++ config/arm/unwind-arm.c     (working copy)
@@ -61,6 +61,7 @@
 #define UCB_PR_ADDR(ucbp) ((ucbp)->unwinder_cache.reserved2)
 #define UCB_SAVED_CALLSITE_ADDR(ucbp) ((ucbp)->unwinder_cache.reserved3)
 #define UCB_FORCED_STOP_ARG(ucbp) ((ucbp)->unwinder_cache.reserved4)
+#define UCB_SIGNAL_FRAME(ucbp) ((ucbp)->unwinder_cache.reserved5)

 struct core_regs
 {
@@ -595,7 +596,14 @@
 {
   const __EIT_entry * eitp;
   int nrec;
-
+
+  {
+    _uw *pc = (_uw *)(return_address & ~3);
+     UCB_SIGNAL_FRAME(ucbp) <<= 1;
+     UCB_SIGNAL_FRAME(ucbp)
+       |= pc[0] == 0xe3a070ad && pc[1] == 0xef000000;
+  }
+
   /* The return address is the address of the instruction following the
      call instruction (plus one in thumb mode).  If this was the last
      instruction in the function the address will lie in the following
@@ -941,6 +949,15 @@
 }


+_Unwind_Word
+_Unwind_IsSignalFrame (_Unwind_Context *context)
+{
+  _Unwind_Control_Block *ucbp
+    = (_Unwind_Control_Block *)_Unwind_GetGR (context, 12);
+  return (UCB_SIGNAL_FRAME (ucbp) & 2) != 0;
+}
+
+
 /* Free an exception.  */

 void
Index: config/arm/unwind-arm.h
===================================================================
--- config/arm/unwind-arm.h     (revision 178028)
+++ config/arm/unwind-arm.h     (working copy)
@@ -217,6 +217,8 @@
   _Unwind_Reason_Code __gnu_unwind_execute (_Unwind_Context *,
                                            __gnu_unwind_state *);

+  _Unwind_Word _Unwind_IsSignalFrame (_Unwind_Context *context);
+
   /* Decode an R_ARM_TARGET2 relocation.  */
   static inline _Unwind_Word
   _Unwind_decode_target2 (_Unwind_Word ptr)
@@ -254,7 +256,8 @@
   (_Unwind_GetGR (context, 15) & ~(_Unwind_Word)1)

 #define _Unwind_GetIPInfo(context, ip_before_insn) \
-  (*ip_before_insn = 0, _Unwind_GetGR (context, 15) & ~(_Unwind_Word)1)
+    (*ip_before_insn = _Unwind_IsSignalFrame (context), \
+      _Unwind_GetGR (context, 15) & ~(_Unwind_Word)1)

   static inline void
   _Unwind_SetGR (_Unwind_Context *context, int regno, _Unwind_Word val)




[-- Attachment #2: segv.cc --]
[-- Type: text/plain, Size: 509 bytes --]

#define _POSIX_SOURCE

#include <signal.h>
#include <stdio.h>

int *a;

class FoobarException
{
  int thingy;
};

void signal_handler(int signum, siginfo_t *info, void *)
{
  FoobarException *f = new FoobarException;
  throw f;
}

int main()
{
  struct sigaction act;

  act.sa_sigaction = signal_handler;
  sigemptyset (&act.sa_mask);
  act.sa_flags = SA_SIGINFO;
  sigaction (11, &act, NULL);

  try
    {
      printf("%d\n", *a);
    }
  catch (FoobarException *f)
    {
      printf("Hello!\n");
    }
}

Re: ARM Linux EABI: unwinding through a segfault handler

[David Daney]

On 08/25/2011 05:26 AM, Andrew Haley wrote:
> Throwing an exception through a segfault handler doesn't always work
> on ARM: the attached example fails on current gcc trunk.
>
> panda-9:~ $ g++ segv.cc -fnon-call-exceptions -g
> panda-9:~ $ ./a.out
> terminate called after throwing an instance of 'FoobarException*'
> Aborted
>
> The bug is that _Unwind_GetIPInfo doesn't correctly set ip_before_insn.
> Instead, it always sets it to zero; it should be set to 1 if this
> is a frame created by a signal handler:
>
>
> #define _Unwind_GetIPInfo(context, ip_before_insn) \
>    (*ip_before_insn = 0, _Unwind_GetGR (context, 15)&  ~(_Unwind_Word)1)
>
>
> Fixing this on ARM is hard because signal frames aren't specially
> marked as they are on systems that use DWARF unwinder data.  I have
> a patch that works on systems where the signal restorer is exactly
>
>          mov     r7, $SYS_rt_sigreturn
>          swi     0x0
>
> It works as a proof of concept, but it's fugly.

For what it's worth, I did the equivalent on MIPS.

Once you do this, it is a de facto ABI.  Probably the ARM linux 
maintainers should be consulted to see if they are willing to consider 
the possibility of never changing it.

I think all Linux ABIs should support unwinding through signal handlers, 
so adding this makes sense to me.

David Daney

>
> So, suggestions welcome.  Is there a nice way to detect a signal frame?
>

Re: ARM Linux EABI: unwinding through a segfault handler

[Andrew Haley]

On 08/25/2011 05:57 PM, David Daney wrote:
> On 08/25/2011 05:26 AM, Andrew Haley wrote:
>> Throwing an exception through a segfault handler doesn't always work
>> on ARM: the attached example fails on current gcc trunk.
>>
>> panda-9:~ $ g++ segv.cc -fnon-call-exceptions -g
>> panda-9:~ $ ./a.out
>> terminate called after throwing an instance of 'FoobarException*'
>> Aborted
>>
>> The bug is that _Unwind_GetIPInfo doesn't correctly set ip_before_insn.
>> Instead, it always sets it to zero; it should be set to 1 if this
>> is a frame created by a signal handler:
>>
>>
>> #define _Unwind_GetIPInfo(context, ip_before_insn) \
>>    (*ip_before_insn = 0, _Unwind_GetGR (context, 15)&  ~(_Unwind_Word)1)
>>
>>
>> Fixing this on ARM is hard because signal frames aren't specially
>> marked as they are on systems that use DWARF unwinder data.  I have
>> a patch that works on systems where the signal restorer is exactly
>>
>>          mov     r7, $SYS_rt_sigreturn
>>          swi     0x0
>>
>> It works as a proof of concept, but it's fugly.
> 
> For what it's worth, I did the equivalent on MIPS.
> 
> Once you do this, it is a de facto ABI.  Probably the ARM linux 
> maintainers should be consulted to see if they are willing to consider 
> the possibility of never changing it.

I think Joseph Meyers is the author of both ends of this, and I think he
reads this list.

Andrew.

Re: ARM Linux EABI: unwinding through a segfault handler

[Ken Werner]

On 08/25/2011 02:26 PM, Andrew Haley wrote:
> Throwing an exception through a segfault handler doesn't always work
> on ARM: the attached example fails on current gcc trunk.
>
> panda-9:~ $ g++ segv.cc -fnon-call-exceptions -g
> panda-9:~ $ ./a.out
> terminate called after throwing an instance of 'FoobarException*'
> Aborted
>
> The bug is that _Unwind_GetIPInfo doesn't correctly set ip_before_insn.
> Instead, it always sets it to zero; it should be set to 1 if this
> is a frame created by a signal handler:
>
>
> #define _Unwind_GetIPInfo(context, ip_before_insn) \
>    (*ip_before_insn = 0, _Unwind_GetGR (context, 15)&  ~(_Unwind_Word)1)
>
>
> Fixing this on ARM is hard because signal frames aren't specially
> marked as they are on systems that use DWARF unwinder data.  I have
> a patch that works on systems where the signal restorer is exactly
>
>          mov     r7, $SYS_rt_sigreturn
>          swi     0x0
>
> It works as a proof of concept, but it's fugly.
>
> So, suggestions welcome.  Is there a nice way to detect a signal frame?

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

Regards
Ken

Re: ARM Linux EABI: unwinding through a segfault handler

[Daniel Jacobowitz]

On Mon, Aug 29, 2011 at 11:18 AM, Ken Werner <ken.werner@linaro.org> wrote:
> On 08/25/2011 02:26 PM, Andrew Haley wrote:
>>
>> Throwing an exception through a segfault handler doesn't always work
>> on ARM: the attached example fails on current gcc trunk.
>>
>> panda-9:~ $ g++ segv.cc -fnon-call-exceptions -g
>> panda-9:~ $ ./a.out
>> terminate called after throwing an instance of 'FoobarException*'
>> Aborted
>>
>> The bug is that _Unwind_GetIPInfo doesn't correctly set ip_before_insn.
>> Instead, it always sets it to zero; it should be set to 1 if this
>> is a frame created by a signal handler:
>>
>>
>> #define _Unwind_GetIPInfo(context, ip_before_insn) \
>>   (*ip_before_insn = 0, _Unwind_GetGR (context, 15)&  ~(_Unwind_Word)1)
>>
>>
>> Fixing this on ARM is hard because signal frames aren't specially
>> marked as they are on systems that use DWARF unwinder data.  I have
>> a patch that works on systems where the signal restorer is exactly
>>
>>         mov     r7, $SYS_rt_sigreturn
>>         swi     0x0
>>
>> It works as a proof of concept, but it's fugly.
>>
>> So, suggestions welcome.  Is there a nice way to detect a signal frame?
>
> 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.

-- 
Thanks,
Daniel

Re: ARM Linux EABI: unwinding through a segfault handler

[Andrew Haley]

On 08/29/2011 06:13 PM, Daniel Jacobowitz wrote:
> On Mon, Aug 29, 2011 at 11:18 AM, Ken Werner <ken.werner@linaro.org> wrote:
>> On 08/25/2011 02:26 PM, Andrew Haley wrote:
>>>
>>> Throwing an exception through a segfault handler doesn't always work
>>> on ARM: the attached example fails on current gcc trunk.
>>>
>>> panda-9:~ $ g++ segv.cc -fnon-call-exceptions -g
>>> panda-9:~ $ ./a.out
>>> terminate called after throwing an instance of 'FoobarException*'
>>> Aborted
>>>
>>> The bug is that _Unwind_GetIPInfo doesn't correctly set ip_before_insn.
>>> Instead, it always sets it to zero; it should be set to 1 if this
>>> is a frame created by a signal handler:
>>>
>>>
>>> #define _Unwind_GetIPInfo(context, ip_before_insn) \
>>>   (*ip_before_insn = 0, _Unwind_GetGR (context, 15)&  ~(_Unwind_Word)1)
>>>
>>>
>>> Fixing this on ARM is hard because signal frames aren't specially
>>> marked as they are on systems that use DWARF unwinder data.  I have
>>> a patch that works on systems where the signal restorer is exactly
>>>
>>>         mov     r7, $SYS_rt_sigreturn
>>>         swi     0x0
>>>
>>> It works as a proof of concept, but it's fugly.
>>>
>>> So, suggestions welcome.  Is there a nice way to detect a signal frame?
>>
>> 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 don't for ARM, and indeed we can't.  ARM unwind frames don't have
any way of encoding the fact that they're signal frames or AFAICS of
encoding the return address offset.

Andrew.

Re: ARM Linux EABI: unwinding through a segfault handler

[Joseph S. Myers]

On Mon, 29 Aug 2011, Daniel Jacobowitz wrote:

> I thought we used a handler in GLIBC that was properly annotated,
> nowadays, but I might be mistaken.

What we have in GLIBC is 
ports/sysdeps/unix/sysv/linux/arm/eabi/sigrestorer.S.  Note that 
sigaction.c has to check the kernel version to determine which function to 
use because 2.6.18 changed the signal frame layout, not realising that it 
was part of the userspace ABI.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: ARM Linux EABI: unwinding through a segfault handler

[Paul Brook]

> >> 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?

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

Paul

Re: ARM Linux EABI: unwinding through a segfault handler

[Andrew Haley]

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.

Re: ARM Linux EABI: unwinding through a segfault handler

[Paul Brook]

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

You've missed several logic step there :-)  On ARM the frame unwinding is 
performed by the personality routine.  The unwinding library has no business 
poking its nose in.
 
> > 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.

IMO you're fixing the wrong problem.  Instead you should advance the IP when 
unwinding the frame.  Given the unwinding tables for sa_restorer are already 
borken you may as well fix both at once :-)

Paul

Re: ARM Linux EABI: unwinding through a segfault handler

[Andrew Haley]

On 10/27/2011 12:53 PM, Paul Brook wrote:
>> 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.
>
> You've missed several logic step there :-)  On ARM the frame unwinding is
> performed by the personality routine.  The unwinding library has no business
> poking its nose in.

OK, so I need a way to fix the personality routine.

>>> 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.
>
> IMO you're fixing the wrong problem.  Instead you should advance the IP when
> unwinding the frame.  Given the unwinding tables for sa_restorer are already
> borken you may as well fix both at once :-)

I'm trying to understand what you mean, but your comments are rather obscure.
Which file do you think I should change?  Just tell me where to look and
I'll do it.

Andrew.

Re: ARM Linux EABI: unwinding through a segfault handler

[Paul Brook]

> I'm trying to understand what you mean, but your comments are rather
> obscure. Which file do you think I should change?  Just tell me where to
> look and I'll do it.

glibc/ports/sysdeps/unix/sysv/linux/arm/eabi/sigrestorer.S Currently has:

        .fnstart
        .save {r0-r15}
        .pad #32
        nop
ENTRY(__default_sa_restorer_v2)
        mov     r7, $SYS_ify(sigreturn)
        swi     0x0
        .fnend

This needs changing to:

        .fnstart
        .personality __gnu_personality_sigframe
        nop
ENTRY(__default_sa_restorer_v2)
        mov     r7, $SYS_ify(sigreturn)
        swi     0x0
        .fnend

The implementation of __gnu_personality_sigframe looks something like:

#include <unwind.h>

static void adjust_sp(context, int n)
{
  _Unwind_Word sp;

  _Unwind_VRS_Get (context, _UVRSC_CORE, R_SP, _UVRSD_UINT32, &sp);
  sp += n;
  _Unwind_VRS_Set (context, _UVRSC_CORE, R_SP, _UVRSD_UINT32, &sp);
}

static uint32_t get_cpsr(context)
{
  return sp[...];
}

_Unwind_Reason_Code
__gnu_personality_sigframe (_Unwind_State state,
                        _Unwind_Control_Block *ucbp,
                        _Unwind_Context *context)
{
  int reg;
  uint32_t cpsr;
  uint32_t pc;
  uint32_t *sp;

  /* We never have any handlers or cleanups.
   Just Unwind the signal frame and keep going.  */

  _Unwind_VRS_Get (context, _UVRSC_CORE, R_SP, _UVRSD_UINT32, &sp);
  sp -= ...;
  if (GLRO (dl_hwcap) & HWCAP_ARM_VFP)
    {
      foreach(vfp_reg)
        _Unwind_VRS_Set(context, _UVRSC_VFP, ..., _UVRSD_DOUBLE, &sp[...]);
      /* Don't forget about VFP3 (i.e. D16-D31 if they exist).  */
    }
  foreach(core_reg)
    _Unwind_VRS_Set (context, _UVRSC_CORE, ..., _UVRSD_UINT32, &sp[...]);
  pc = sp[...];
  cpsr = sp[...];
  /* Set mode bit from saved CPSR.  */
  pc &= ~1;
  if (cpsr & CPSR_T)
    pc |= 1;
  /* Advance PC past the faulting instruction.  */
  if ((cpsr & CPSR_T) && (*(uint16_t *)(pc & ~1) < 0xe800))
    pc += 2;
  else
    pc += 4;
  _Unwind_VRS_Set (context, _UVRSC_CORE, R_PC, _UVRSD_UINT32, &pc);

  /* We don't/can't restore CPSR and FPSR.  However the EABI requires these
     have fixed values at public entry points.  Hope that subsequent
     catch/cleanup handlers are ok with that value.  */
  return _URC_CONTINUE_UNWIND;
}

For bonus points have __gnu_personality_sigframe automagically handle bit old 
and new layouts, removing the _v1/_v2 hacks.

Paul

Re: ARM Linux EABI: unwinding through a segfault handler

[mads_bn]

Paul, do you know of any progress on this since 2011?

I cannot find any attempt to use your suggested ".personality
__gnu_personality_sigframe" in prologue for "__default_sa_restorer_v2".
I still need to learn more about this syntax...
I'm not building the glibc myself, but can probably let a friend try it if
we believe it is the right fix.

We hope to be able to make some poor man's backtrace's in syslog, when fatal
signals occurs in embedded systems (SIGSEGV, abort->SIGABRT etc).
This was quite useful on x86 targets in the past.

We are currently upgrading from EGLIBC 2.16 to 2.19 (yocto builds) and I
also tried to browse the regular GLIBC head.
With EGLIBC 2.16 I made a small test program and the backtrace always
stopped at gsignal(),
but if my signal_handler then triggered a coredump using raise(SIGQUIT) then
gdb was able to backtrace beyond the signal handler (see below).

http://www.eglibc.org/cgi-bin/viewvc.cgi/branches/eglibc-2_19/libc/ports/sysdeps/unix/sysv/linux/arm/sigrestorer.S?view=markup
<http://www.eglibc.org/cgi-bin/viewvc.cgi/branches/eglibc-2_19/libc/ports/sysdeps/unix/sysv/linux/arm/sigrestorer.S?view=markup>  
https://sourceware.org/git/?p=glibc.git;a=history;f=sysdeps/unix/sysv/linux/arm/sigrestorer.S;h=71f9e25804bedb58cb06396834e8cea05dedc191;hb=refs/heads/master
<https://sourceware.org/git/?p=glibc.git;a=history;f=sysdeps/unix/sysv/linux/arm/sigrestorer.S;h=71f9e25804bedb58cb06396834e8cea05dedc191;hb=refs/heads/master>   

arm7$ ./test
# backtrace before signal raised
backtrace() returned 6 addresses
libdemo.so(_Z11doBacktracePKci+0x44) [0xb6f3ae38]
libdemo.so(_Z2f3v+0x1c) [0xb6f3af24]
libdemo.so(_Z2f2v+0x20) [0xb6f3af54]
libdemo.so(_Z2f1v+0x28) [0xb6f3af8c]
./test() [0x8740]
/lib/libc.so.6(__libc_start_main+0x110) [0x444b7ea8]
abort
# backtrace after signal raised, signal_handler dumps backtrace and raise
SIGQUIT to core dump
--8<-------------------- Stack --------------------8<--
Error: signal 6:
libdemo.so(_ZN14doBacktraceEi+0x30)[0xb6f3b4f8]
libdemo.so(_ZN14signal_handlerEi+0x134)[0xb6f3b3b4]
/lib/libc.so.6(__default_sa_restorer_v2+0x0)[0x444ce1d0]
/lib/libc.so.6(gsignal+0x3c)[0x444ccf28]
--8<-----------------------------------------------8<--
Quit (core dumped)
===========
$ gdb test core
...
Program terminated with signal 3, Quit.
#0  0x444ccf28 in raise () from /lib/libc.so.6
(gdb) bt
#0  0x444ccf28 in raise () from /lib/libc.so.6
#1  0xb6f3b488 in signal_handler (sig=6) at mysignalhandler.cpp:176
#2  <signal handler called>
#3  0x444ccf28 in raise () from /lib/libc.so.6
#4  0x444d09a8 in abort () from /lib/libc.so.6
#5  0xb6f3afc0 in f1 () at foo.cpp:57
#6  0x00008740 in main ()



--
View this message in context: http://gcc.1065356.n5.nabble.com/ARM-Linux-EABI-unwinding-through-a-segfault-handler-tp692287p1117716.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: ARM Linux EABI: unwinding through a segfault handler

[Matthijs van Duin]

I've managed to expand Paul's outline into working code. It's still
incomplete but I can report success throwing an exception in a signal
handler and catching it outside it.

I didn't rebuild glibc but just linked some extra code to my executable.
The <unwind.h> I grabbed from glibc, the rest are system headers.

Note that this version doesn't cover the use of SA_SIGINFO nor the old
v1 format, and currently doesn't restore VFP registers yet.  It also
needs to restore the signal mask.  I'm hoping it's safe to do that in
the location where I've marked the TODO in my code, but I have the
feeling this is the sort of code that can easily have ugly corner cases
or race conditions...  manually restoring the signal mask after catching
the exception might be safer.


// sigrestorer.S

.syntax unified
.global __default_sa_restorer_v2
	.fnstart 
	.personality __gnu_personality_sigframe 
	nop 
__default_sa_restorer_v2:
	mov	r7, 139  // sigreturn
	svc	0
	.fnend 


// gnu_personality_sigframe.c

#include <unwind.h>
#include <ucontext.h>
#include <signal.h>
#include <stdbool.h>

struct sigframe {
	struct ucontext uc;
	unsigned long retcode[2];
};

static inline _uw get_core_reg( _Unwind_Context *context, _uw reg )
{
	_uw val;
	_Unwind_VRS_Get( context, _UVRSC_CORE, reg, _UVRSD_UINT32, &val );
	return val;
}

static inline void set_core_reg( _Unwind_Context *context, _uw reg, _uw val )
{
	_Unwind_VRS_Set( context, _UVRSC_CORE, reg, _UVRSD_UINT32, &val );
}

#define R_SP 13
#define R_LR 14
#define R_PC 15

#define T_BIT ( 1 << 5 )

_Unwind_Reason_Code
__gnu_personality_sigframe( _Unwind_State state, 
		_Unwind_Control_Block *ucbp, 
		_Unwind_Context *context )
{
	bool for_realzies;

	switch( state ) {
	case _US_VIRTUAL_UNWIND_FRAME:
		for_realzies = false;
		break;
	case _US_UNWIND_FRAME_STARTING:
		for_realzies = true;
		break;
	default:
		return _URC_FAILURE;
	}

	struct sigframe *sf = (struct sigframe *) get_core_reg( context, R_SP );

	// basically replicate restore_sigframe() in arch/arm/kernel/signal.c

	_uw *reg = &sf->uc.uc_mcontext.arm_r0;
	for( int i = 0; i < 15; i++ )
		set_core_reg( context, i, reg[i] );
	_uw pc = sf->uc.uc_mcontext.arm_pc;
	_uw psr = sf->uc.uc_mcontext.arm_cpsr;
	// advance PC and set bit 0 to indicate thumb state
	if( psr & T_BIT ) {
		bool thumb32 = *(_uw16 *) pc >= 0xe800;
		pc += thumb32 ? 4 : 2;
		pc |= 1;
	} else {
		pc += 4;
	}
	set_core_reg( context, R_PC, pc );

	// TODO vfp

	if( for_realzies ) {
		// XXX restore sigmask, vfp control registers, etc?
	}

	return _URC_CONTINUE_UNWIND;
}

Re: ARM Linux EABI: unwinding through a segfault handler

[Matthijs van Duin]

A shiny revised version of my unwind-through-signal code for ARM EABI:

https://github.com/mvduin/arm-signal-unwind/

For actual unwinding it now uses sigreturn as a cleanup handler (after
diddling the ucontext to make it land right onto a call to
_Unwind_Resume), which means that all state should get properly
restored by the kernel.

Virtual unwinding still only restores core registers, but hopefully
that isn't too big a problem in practice.

A small test is included that confirms throwing exceptions out of
SEGV, checks VFP is restored properly, and that returning normally
from an async signal handler still works (my original patch accidently
broke that).

I'd finally like to take a moment to say this was hell to figure
out.... this shit is really documented nowhere properly since it
appears to be a magic blend of ARM EABI and IA64 C++ ABI (meaning
neither documentation quite applies) and I had to plow through the
innards of libgcc and libsupc++ to figure out how things *actually*
work. Argh.

Anyhow, it only took four years, but you can now throw
NullPointerExceptions on ARM. Enjoy. ;-)

Matthijs van Duin

Re: ARM Linux EABI: unwinding through a segfault handler

[Andrew Haley]

On 03/10/15 21:41, Matthijs van Duin wrote:
> Anyhow, it only took four years, but you can now throw
> NullPointerExceptions on ARM. Enjoy. ;-)

Ok, nice.  :-)

Do you have GCC copyright assignment, and will you turn this into
a patch which can be applied?

Thanks,
Andrew.

Re: ARM Linux EABI: unwinding through a segfault handler

[Matthijs van Duin]

On 4 October 2015 at 10:05, Andrew Haley <aph@redhat.com> wrote:
> Do you have GCC copyright assignment

No, but I hereby license it under the http://www.wtfpl.net/ (or, in
any legal system which acknowledges such an act, place it in public
domain)

> will you turn this into a patch which can be applied?

I've already spent way more effort on this than I originally planned
to. But feel free to turn it into patch which can be applied.

Re: ARM Linux EABI: unwinding through a segfault handler

[Ian Lance Taylor]

On Sun, Oct 4, 2015 at 5:09 AM, Matthijs van Duin
<matthijsvanduin@gmail.com> wrote:
> On 4 October 2015 at 10:05, Andrew Haley <aph@redhat.com> wrote:
>> Do you have GCC copyright assignment
>
> No, but I hereby license it under the http://www.wtfpl.net/ (or, in
> any legal system which acknowledges such an act, place it in public
> domain)

Unfortunately, the FSF requires a paper signature.  We can't accept a
significant patch without it.  I'll send you the form separately.
Thanks for contributing to GCC.

Ian

Re: ARM Linux EABI: unwinding through a segfault handler

[mads_bn]

Paul, do you know of any progress on this since 2011?

I cannot find any attempt to use your suggested ".personality
__gnu_personality_sigframe" in prologue for "__default_sa_restorer_v2".
I still need to learn more about this syntax...
I'm not building the glibc myself, but can probably let a friend try it if
we believe it is the right fix.

We hope to be able to make some poor man's backtrace's in syslog, when fatal
signals occurs in embedded systems (SIGSEGV, abort->SIGABRT etc).
This was quite useful on x86 targets in the past.

We are currently upgrading from EGLIBC 2.16 to 2.19 (yocto builds) and I
also tried to browse the regular GLIBC head.
With EGLIBC 2.16 I made a small test program and the backtrace always
stopped at gsignal(),
but if my signal_handler then triggered a coredump using raise(SIGQUIT) then
gdb was able to backtrace beyond the signal handler (see below).

http://www.eglibc.org/cgi-bin/viewvc.cgi/branches/eglibc-2_19/libc/ports/sysdeps/unix/sysv/linux/arm/sigrestorer.S?view=markup
<http://www.eglibc.org/cgi-bin/viewvc.cgi/branches/eglibc-2_19/libc/ports/sysdeps/unix/sysv/linux/arm/sigrestorer.S?view=markup>  
https://sourceware.org/git/?p=glibc.git;a=history;f=sysdeps/unix/sysv/linux/arm/sigrestorer.S;h=71f9e25804bedb58cb06396834e8cea05dedc191;hb=refs/heads/master
<https://sourceware.org/git/?p=glibc.git;a=history;f=sysdeps/unix/sysv/linux/arm/sigrestorer.S;h=71f9e25804bedb58cb06396834e8cea05dedc191;hb=refs/heads/master>   

arm7$ ./test
# backtrace before signal raised
backtrace() returned 6 addresses
libdemo.so(_Z11doBacktracePKci+0x44) [0xb6f3ae38]
libdemo.so(_Z2f3v+0x1c) [0xb6f3af24]
libdemo.so(_Z2f2v+0x20) [0xb6f3af54]
libdemo.so(_Z2f1v+0x28) [0xb6f3af8c]
./test() [0x8740]
/lib/libc.so.6(__libc_start_main+0x110) [0x444b7ea8]
abort
# backtrace after signal raised, signal_handler dumps backtrace and raise
SIGQUIT to core dump
--8<-------------------- Stack --------------------8<--
Error: signal 6:
libdemo.so(_ZN14doBacktraceEi+0x30)[0xb6f3b4f8]
libdemo.so(_ZN14signal_handlerEi+0x134)[0xb6f3b3b4]
/lib/libc.so.6(__default_sa_restorer_v2+0x0)[0x444ce1d0]
/lib/libc.so.6(gsignal+0x3c)[0x444ccf28]
--8<-----------------------------------------------8<--
Quit (core dumped)
===========
$ gdb test core
...
Program terminated with signal 3, Quit.
#0  0x444ccf28 in raise () from /lib/libc.so.6
(gdb) bt
#0  0x444ccf28 in raise () from /lib/libc.so.6
#1  0xb6f3b488 in signal_handler (sig=6) at mysignalhandler.cpp:176
#2  <signal handler called>
#3  0x444ccf28 in raise () from /lib/libc.so.6
#4  0x444d09a8 in abort () from /lib/libc.so.6
#5  0xb6f3afc0 in f1 () at foo.cpp:57
#6  0x00008740 in main ()



--
View this message in context: http://gcc.1065356.n5.nabble.com/ARM-Linux-EABI-unwinding-through-a-segfault-handler-tp692287p1117717.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: ARM Linux EABI: unwinding through a segfault handler

[prafullakota]

Hi,

We are also observing same issue and this was fixed in ulibc in below link
and we are looking for any solution if exists in glibc similar to this.
Please let us know.

http://lists.uclibc.org/pipermail/uclibc/2013-September/047932.html

Thanks,
Prafulla



--
View this message in context: http://gcc.1065356.n5.nabble.com/ARM-Linux-EABI-unwinding-through-a-segfault-handler-tp692287p1056478.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

SV: ARM Linux EABI: unwinding through a segfault handler

[mads_bn]

Nice work !

 

Some time ago I was in a project, where we would like to get more context in
syslog when e.g. SIGSEGV occurred (embedded Linux).

On x86 this was working fine, and I hope a change like this for ARM will
allow it to work here as well (as long as stack is still valid).

 

I don't have access to such an ARM setup currently.

Can somebody try if e.g. backtrace_symbols () will show where the offending
code was called from?

http://linux.die.net/man/3/backtrace_symbols 

 

Also I really like the idea to get this back into the mainstream version, so
we all will benefit from it in future ;-)

 

/Mads

 

Fra: Matthijs van Duin [via gcc]
[mailto:ml-node+s1065356n1191196h83@n5.nabble.com] 
Sendt: 3. oktober 2015 22:42
Til: mads_bn <madsbn@mail.dk>
Emne: Re: ARM Linux EABI: unwinding through a segfault handler

 

A shiny revised version of my unwind-through-signal code for ARM EABI: 

https://github.com/mvduin/arm-signal-unwind/

For actual unwinding it now uses sigreturn as a cleanup handler (after 
diddling the ucontext to make it land right onto a call to 
_Unwind_Resume), which means that all state should get properly 
restored by the kernel. 

Virtual unwinding still only restores core registers, but hopefully 
that isn't too big a problem in practice. 

A small test is included that confirms throwing exceptions out of 
SEGV, checks VFP is restored properly, and that returning normally 
from an async signal handler still works (my original patch accidently 
broke that). 

I'd finally like to take a moment to say this was hell to figure 
out.... this shit is really documented nowhere properly since it 
appears to be a magic blend of ARM EABI and IA64 C++ ABI (meaning 
neither documentation quite applies) and I had to plow through the 
innards of libgcc and libsupc++ to figure out how things *actually* 
work. Argh. 

Anyhow, it only took four years, but you can now throw 
NullPointerExceptions on ARM. Enjoy. ;-) 

Matthijs van Duin 



  _____  

If you reply to this email, your message will be added to the discussion
below:

http://gcc.1065356.n5.nabble.com/ARM-Linux-EABI-unwinding-through-a-segfault
-handler-tp692287p1191196.html 

To unsubscribe from ARM Linux EABI: unwinding through a segfault handler,
click here
<http://gcc.1065356.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe
_by_code&node=692287&code=bWFkc2JuQG1haWwuZGt8NjkyMjg3fDIwNDQ1NTEzNzU=> .
 
<http://gcc.1065356.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewe
r&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNam
espace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.Nod
eNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emai
ls%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> NAML 





--
View this message in context: http://gcc.1065356.n5.nabble.com/SV-ARM-Linux-EABI-unwinding-through-a-segfault-handler-tp1191260.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: ARM Linux EABI: unwinding through a segfault handler

[Matthijs van Duin]

On 4 October 2015 at 10:50, mads_bn <madsbn@mail.dk> wrote:
> Can somebody try if e.g. backtrace_symbols () will show where the offending
> code was called from?

Included a backtrace test, pushed to github.

./test(_Z9backtracev+0xb)[0x10f28]
./test(_Z17backtrace_handleri+0x5)[0x10f4a]     <---- signal handler
./test[0x112b6]     <---- __default_rt_sa_restorer_v2 (my version)
./test(_Z9test_segvf+0xd)[0x10f6e]      <--- NULL dereference
...

It's a bit awkward that it can only show dynamic symbols and doesn't
demangle them. There are probably better backtrace-generators out
there.

An unpleasant surprise was that installing an std::terminate_handler
made an uncaught exception *less* informative rather than more:

./test(_Z9backtracev+0xb)[0x10f28]
./test(_Z15abort_backtracev+0x5)[0x10f3e]
/lib/libstdc++.so.6(+0x6f1c8)[0xf67121c8]
qemu: uncaught target signal 6 (Aborted) - core dumped

versus

terminate called after throwing an instance of 'IntendedUncaughtException'
qemu: uncaught target signal 6 (Aborted) - core dumped

I thought the whole idea behind two-phase unwinding was to leave the
stack intact for inspection on an uncaught exception. Oh well...

> I don't have access to such an ARM setup currently

As shown above, an ARM setup is one "apt-get install qemu-user" away ;-)

Matthijs