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: jimb at zwingli dot cygnus dot com (Jim Blandy)
- Subject: Re: [PATCH]: Make Sparc Target Multi-Arch
- From: "Peter.Schauer" <Peter dot Schauer at regent dot e-technik dot tu-muenchen dot de>
- Date: Wed, 3 May 2000 10:47:43 MET DST
- Cc: gdb-patches at sourceware dot cygnus dot com
> > 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.
Which just increases the chance that we clobber code which is actually
called by the user function.
I really vote against putting anything else than a breakpoint at the
ENTRY_POINT in the inferior.
--
Peter Schauer pes@regent.e-technik.tu-muenchen.de