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: Jim Blandy <jimb at cygnus dot com>
- Subject: Re: [PATCH]: Make Sparc Target Multi-Arch
- From: Michael Snyder <msnyder at cygnus dot com>
- Date: Wed, 03 May 2000 07:53:45 -0700
- CC: "Peter.Schauer" <Peter dot Schauer at regent dot e-technik dot tu-muenchen dot de>, gdb-patches at sourceware dot cygnus dot com, taylor at cygnus dot com
- Organization: Cygnus Solutions
- References: <200005022046.WAA14084@reisser.regent.e-technik.tu-muenchen.de> <npvh0wf8m3.fsf@zwingli.cygnus.com>
- Reply-To: msnyder at cygnus dot com
Jim Blandy wrote:
>
> > > 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).
> [...]
> 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.
That would lose as soon as K*N > sizeof(entry_function), 'cause
then we might be putting call_dummy breakpoints in code that
might be called.