On 07/28/2011 12:27 AM, Alan Modra wrote:
> On Wed, Jul 27, 2011 at 03:00:45PM +0930, Alan Modra wrote:
>> Ideally what I'd like to
>> do is have ld and gcc emit accurate r2 tracking unwind info and
>> dispense with hacks like frob_update_context. If ld did emit accurate
>> unwind info for .glink, then the justification for frob_update_context
>> disappears.
>
> For the record, this statement of mine doesn't make sense. A .glink
> stub doesn't make a frame, so a backtrace won't normally pass through a
> stub, thus having accurate unwind info for .glink doesn't help at all.
It does, for the duration of the stub.
The whole problem is that toc pointer copy in 40(1) is only valid
during indirect call sequences, and iff ld inserted a stub? I.e.
direct calls between functions that share toc pointers never save
the copy?
Would it make sense, if a function has any indirect call, to move
the toc pointer save into the prologue? You'd get to avoid that
store all the time. Of course you'd not be able to sink the load
after the call, but it might still be a win. And in that special
case you can annotate the r2 save slot just once, correctly.
For functions that do not contain an indirect function call, I
don't believe that there's a any way to use DW_CFA_offset that
is always correct.
One could, however, move the code in frob_update_context into a
(series of) DW_CFA_val_expression's.
DW_CFA_val_expression
DW_OP_reg2 // Default to the value currently in R2
DW_OP_regx LR // Test the insn following the call, as per
frob_update_context
DW_OP_deref_size 4
DW_OP_const4u 0xE8410028
DW_OP_ne
DW_OP_bra L1
DW_OP_drop // Could be omitted, given that we only examine
top-of-stack at the end
DW_OP_breg1 40 // Pull the value from *(R1+40)
DW_OP_deref
L1:
This version could appear in the CIE. You'd have to adjust it
once LR gets saved to the stack, and R2 isn't itself being saved
as per above.
There isn't currently a hook in dwarf2cfi to add extra stuff to
the CIE program, but that wouldn't be hard to add. The version
that gets emitted after LR is saved would need a new note as well.
But it all seems fairly tractable to actually implement, if we
think it'll actually solve the problem.
r~
