This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc] [2/4] SPU overlay support: The SPU target part
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: drow at false dot org (Daniel Jacobowitz)
- Cc: emi-suzuki at tjsys dot co dot jp (Emi SUZUKI), gdb-patches at sourceware dot org
- Date: Fri, 11 May 2007 21:09:28 +0200 (CEST)
- Subject: Re: [rfc] [2/4] SPU overlay support: The SPU target part
Daniel Jacobowitz wrote:
> 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.
Sure, I'll add a comment.
> > > 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.
The return stub isn't on the stack either. We'd have to manufacture
an extra zero-sized stack frame between caller and callee, with
special unwind rules to be able to continue the backtrace. I guess
this would be possible somehow, but I still don't see that this would
provide any benefit to most users ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com