Re: [PATCH]: Make Sparc Target Multi-Arch

["Peter.Schauer" <Peter dot Schauer at regent dot e-technik dot tu-muenchen dot de>]

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

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.

-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de