This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: backtrace() from a pthread on ARM


On Mon, May 11, 2009 at 03:06:22PM -0500, Matt Fischer wrote:
> My question is, first of all, is there any ARM ABI (or other
> equivalent) requirement as to what the frame pointer needs to be in
> newly-created threads?  It seems like it would be beneficial for the
> backtrace logic if it were set to an invalid value, so that attempts
> to walk back across the stack would terminate correctly when the
> beginning of the call stack was reached.  I'm not an expert in this
> area, so perhaps I'm just misunderstanding what ought to happen here,
> but in general, is there a way that this is supposed to work
> correctly, or is it just broken by design?

Broken by design; backtrace() doesn't work on ARM.  The ABI doesn't
guarantee any frame layout or frame pointer - and in many cases there
won't be one.  If you have the version in current glibc tottering
along, then it probably means you're compiling with -mapcs-frame.

We've got some local patches to backtrace using ABI-defined unwinding
tables.  The biggest portion of that was improved linker support,
which went into binutils HEAD last week.  It also requires building
glibc and your application with unwind tables, which can be a bit
tricky - but once you do that, backtrace becomes much more reliable.

-- 
Daniel Jacobowitz
CodeSourcery


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]