Re: [RFC][PATCH] Provide stack backtrace interface in libgcc

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

Hello,

> > we're trying to get rid of the requirement to maintain a stack
> > backchain at run-time on s390, while still allowing to generate
> > stack backtraces for debugging purposes.
> > 
> > To this purpose, we've set GCC to always generate DWARF-2 
> > unwind data (CFI records) for every function.  We've also
> > have a patch to gdb that makes use of this information.
> > 
> > However, there's still a couple of problems that prevent us
> > from actually making the switch to turn of the backchain:
> > 
> > - __builtin_return_address / __buitin_frame address
> >   However, I can accept the argument that those simply are not
> >   guaranteed to work with levels > 0, and callers should be 
> >   adapted to use something else if required.
> > 
> > - glibc's backtrace ()
> >   Needs to be rewritten to use DWARF CFIs
> > 
> > - various third-party applications
> >   There are various applications that need to generate backtraces
> >   in error scenarios (e.g. from a SIGSEGV handler) in order to 
> >   allow to diagnose problems occurring at a customer site.
> >   (All major applications like DB2, Oracle, SAP have this requirement.)
> > 
> >   These applications currently contains code (on s390) that tracks 
> >   our backchain information manually.  While this will obviously
> >   stop working once the backchain is removed, the question is with
> >   what to replace that code ...  (glibc's backtrace () provides
> >   only a subset of the information required, in particular no
> >   data about stack contents and saved registers)
> > 
> > 
> > I had originally thought that both glibc (to implement backtrace ())
> > and also third-party applications could be rewritten to make use of
> > the libgcc _Unwind interfaces in order to generate backtraces via
> > DWARF-2 CFI data.
> > 
> > Unfortunately, this does not work, because while libgcc does contain
> > all necessary code, it is not exported.  The only exported interfaces
> > (_Unwind_RaiseException and _Unwind_ForceUnwind) will not just scan
> > the stack, but actually call cleanup routines etc.
> 
> In x86-64 we are having also DWARF only unwinding.  We currently do use
> libgcc for the unwinding, so the sollution should be the same. 
> Perhaps it is wrong when dealing with the cleanups, but we definitly
> should be in the sync.  Zdenek?

we use _Unwind_ForcedUnwind to do backtraces; and I realize that you are
right in that personality routines may do some cleanups etc. We have
just tested it on c code, where it of course does not occur.  IMHO it
should be easy to create a slightly modified variant of
_Unwind_ForcedUnwind that would not call the personality routines,

Zdenek