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

[Daniel Jacobowitz <drow@false.org>]

On Fri, May 11, 2007 at 12:20:05AM +0200, Ulrich Weigand wrote:
> 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

Clever.  Could we have a comment about this in GDB somewhere?
Apologies if there was one; I didn't see it.

> > 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.

Well, they never end up on the stack.  We would if they did.  But this
isn't a big issue to me; I'd be very confused if I stepi'd a
return instruction and ended up somewhere other than the function
listed in the backtrace, but my use of GDB is probably not typical.

-- 
Daniel Jacobowitz
CodeSourcery