Re: [rfc] [2/4] SPU overlay support: The SPU target part

["Ulrich Weigand" <uweigand@de.ibm.com>]

Daniel Jacobowitz wrote:

> (I'm not sure how this ends up detecting an overlay return stub, but
> I'll take your word for it.)

On the SPU, every register is a 16-byte vector register, and that
includes the "link register" 0.  As addresses are only 32 bit
(actually only 18 bit), only the first of four 32-bit slots in
the link register is used to hold the return address.  However,
the whole 128-bit register is always saved/restored on the stack.

This makes it possible to use the remaining slots to hold additional
information needed to handle return jumps crossing an overlay 
boundary.  In those cases, the slots are set up to hold:
  [0] Return stub entry point in the overlay manager
  [1] Partition number of the overlay section to be returned to
  [2] Actual return address in the (restored) overlay section

Thus, when the normal function return is executed, control will
"return" to the overlay manager, which can examine the remaining
slots to determine which overlay section to swap in, and then
transfer control to the actual return address.

What the PC unwinder code does when it sees an unwound link
register of that form is to set the PC to the value in slot 2
of the link register, instead of slot 0 as usual.

Note that there is no stack frame associated with the return
stub at all.

> This is clever, but kind of sneaky.  We show signal return trampolines
> and dummy call trampolines, so I'm not sure why it's necessary to
> hide overlay return stubs.  Do you think this is more useful than
> confusing?

Both signal return and dummy call trampolines are entities the
user actually knows about and wants to see.  The overlay mechanism
is supposed to be fully transparent to the user; I'd compare the
overlay call and return stubs to things like PLT stubs in ELF
-- we don't show those either.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com