This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: [PATCH]: Make Sparc Target Multi-Arch
- To: "Peter.Schauer" <Peter dot Schauer at regent dot e-technik dot tu-muenchen dot de>
- Subject: Re: [PATCH]: Make Sparc Target Multi-Arch
- From: Jim Blandy <jimb at zwingli dot cygnus dot com>
- Date: 03 May 2000 01:31:00 -0500
- Cc: msnyder at cygnus dot com, gdb-patches at sourceware dot cygnus dot com, taylor at cygnus dot com
- References: <200005022046.WAA14084@reisser.regent.e-technik.tu-muenchen.de>
> > What if I write the return struct size to the entry point address,
> > following the trap instruction, and remove it when finished
> > (like the trap instruction)?
>
> This will not work with nested user calls (breakpoint at called function,
> stop there, call another user function [returning a struct :-)]).
> It might be dangerous as well, as the entry point might just contain
> a jump, and you might clobber code which will be called during the user
> function (unlikely, but possible).
When we push a dummy frame, we could save the contents of the return
size word. Then, we could restore that when we pop the dummy frame.
This would still lose if we:
- call a function from GDB
- hit a breakpoint while that call is active
- call another function from GDB, which longjmps over the
dummy frame and causes the first invocation to return
Alternatively, if we're using generic dummy frames, we could put each
breakpoint / return size at a new address. A synthetic call nested N
deep would store its return breakpoint at ENTRY_POINT + K*N, for the
appropriate value of K.