[PATCH]: Make Sparc Target Multi-Arch

Michael Snyder msnyder@cygnus.com
Tue May 2 14:59:00 GMT 2000


Peter.Schauer wrote:
> 
> > > Using AT_ENTRY_POINT will return bad results when calling a Sun cc compiled
> > > function that returns a struct from within GDB.
> > >
> > > Sun cc generates code which checks the expected structure size against
> > > the passed structure size (in the extra word after the call) and does not
> > > copy to the result structure if the sizes don't match.
> > > Below is the disassembly of a function returning a structure with size 16.
> >
> > Yuck!  Well, I can't use ON_STACK, because (a) the stack section
> > is protected against execution in Solaris/Sparc64, and (b) it's
> > too far from the text section for an ordinary jump/call.
> 
> And if C2 security is enabled on Sparc32 ON_STACK will fail as well, as stack
> execution is protected too.
> So using AT_ENTRY is definitely preferable.
> 
> > 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 :-)]).

Oops, right you are.  But if a target call that returns a struct is 
a rarity, then nested target calls that return structs must be 
doubly rare.

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

I agree -- possible, but unlikely.
 
> As the problematic calls are rare (Sun cc compiled 32 bit ABI functions,
> returning structs), I think that we could live with a warning and returning
> garbage in the return value. Personally I'd prefer that over AT_ENTRY
> hacking.

Ah!  So you're saying this is a concern for Sparc32, but not for
Sparc64?
Then I have a solution.  I can easily use ON_STACK for Sparc32, and
AT_ENTRY_POINT for Sparc64.  That's the beauty of multi-arch!  ;-)

Then the only losers will be people who activate C2 security on Sparc32.

What do you think?

Michael


More information about the Gdb-patches mailing list