Re: [RS6000] asynch exceptions and unwind info

[David Edelsohn <dje dot gcc at gmail dot com>]

On Thu, Jul 28, 2011 at 9:27 PM, Alan Modra <amodra@gmail.com> wrote:

> Right, but I was talking about the normal case, where the unwinder
> won't even look at .glink unwind info.
>
>> 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?
>
> Yes.
>
>> 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.
>
> Except that any info about r2 in an indirect call sequence really
> belongs to the *called* function frame, not the callee. ?I woke up
> this morning with the realization that what I'd done in
> frob_update_context for indirect call sequences was wrong. ?Ditto for
> the r2 store that Michael moved into the prologue. ?The only time we
> want the unwinder to restore from that particular save is if r2 isn't
> saved in the current frame.

This discussion seems to be referencing both PLT stubs and pointer
glue.  Indirect calls through a function pointer create a frame, save
R2, and the unwinder can visit that frame.  PLT stub calls are tail
calls, save R2, and the unwinder only would visit the frame if an
exception occurs in the middle of a call.  One also can add lazy
resolution using the glink code, which performs additional work in the
dynamic linker on the first call.

Which has the problem?  Which are you trying to solve?  And how is
your change solving it?

Thanks, David