On Thu, Jul 28, 2011 at 9:27 PM, Alan Modra <amo...@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
