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: Fix unwinding for Thumb-2 libraries


On Mon, Apr 05, 2010 at 08:53:12AM -0700, Richard Henderson wrote:
> >     We can't use push/pop inside the asm because that breaks
> > +   unwinding (i.e. thread cancellation) for this frame.  We can't
> > +   locally save and restore r7, because we do not know if this
> > +   function uses r7 or if it is our caller's r7; if it is our caller's,
> > +   then unwinding will fail higher up the stack.  So we move the
> > +   syscall out of line and provide its own unwind information.  */
> 
> If you've got cfi directives, you *can* manipulate the unwind
> info inside the asm within the current frame.

Unfortunately this is one of the areas where the ARM tables are
different from the DWARF ones.  Two of the many ways they're unlike
DWARF (the two that most often bite me) are:

* The personality routine is responsible for decoding the table.

* The standard tables are context-insensitive.  They describe the
function, not individual instructions.  They're represented as a
mockup of the instructions you'd need to execute to unwind the stack
from a call site.

If the containing function uses r7, then the right unwind instruction
is "vsp += 4".  We don't care about what was in r7 before the asm(); it's a
local value for the current function.  Some local variable will fail to
print in the debugger because DW_AT_location isn't updated but we're
otherwise OK.

If the containing function doesn't use r7 then the right unwind
instruction is "pop { r7 }".  The value we saved is our caller's.

Do you see any way around that?


Going back to the frame pointer issue, there are two other
conclusions.  Using frame pointers on Thumb-2 generates lousy code.

* Since it's already lousy, the code size bloat from picking r11
instead of r7 would be pretty small.  I didn't want to tie this fix to
a patched GCC, but that'd be one way to handle it.

* GCC is doing OK eliminating the frame pointer.  This only comes up
because GLIBC uses alloca all over the place.

-- 
Daniel Jacobowitz
CodeSourcery


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