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 3:12 PM, Daniel Jacobowitz <drow@false.org> wrote:
> 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
>

Yeah, we're compiling with -mapcs-frame.  Obviously, things get messed
up if there's any code that doesn't have frame pointers, but as long
as those are there, things actually seem to work pretty well.  The
only tricky bit is with recognizing the top of the stack in subsidiary
threads, and even that isn't normally a problem, because after a frame
or two it generally hits some pointer that's recognizably outside of
the stack range, and the stack walk ceases.  It's just every now and
again where we actually vector off into bad memory and the program
crashes.

I'm not sure I'm comfortable pulling in a new infrastructural change
like your unwind table patches seem to be, especially given that
things are working pretty much correctly for us already.  Is there
some sort of hackery that could be done to the existing code that
would get us around this specific problem, in the specific case of
-mapcs-frame and no -fomit-frame-pointer?

--Matt


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