This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: fix to noexec_user_stack on solaris 2.{6,7}


No, any call from GDB to a user function returning a struct/union will
fail miserably. Try this:

struct x
{
  int a[4];
};

struct x gx;

struct x
sret ()
{
  return gx;
}

main ()
{
  int i;
  for (i = 0; i < 4; i++)
    gx.a[i] = i + 1;
  gx = sret ();
}

Set a breakpoint at the gx = sret () statement, run to it and issue a
`print sret()'. It will not succed with your approach, and I doubt that
continuing the program will work as well.

For details of the ABI see the Sparc Architecture Manual.
I have Version 8 (Prentice Hall ISBN 0-13-825001-4) and the calling
conventions for functions returning aggregate values are explained
in Appendix D.3.

> In message <199910200839.KAA17702@reisser.regent.e-technik.tu-muenchen.de>, "Pe
> ter.Schauer" writes:
> >This will break calling of functions that return a structure or union.
> >
> >As per sparc calling conventions the call must looks like this:
> >
> >        call fun,0
> >        nop
> >        unimp <size of returned struct>
> >
> >Setting CALL_DUMMY_LOCATION to AT_ENTRY_POINT doesn't handle this case.
> >
> >When I was looking at the problem a long time ago, I had no idea how to
> >solve it properly.
> 
> Just so I am clear on how this breaks:
> gdb successfully makes the call and returns, but if the return type
> is a struct or union, the size is not correctly reported.  With an
> incorrect size, you can look into the internals of the struct.
> 
> Is that right?  If so, I think I am just going to apply the patch to my
> systems, and be done with it. (Read: "users be damned" :)
> 
> Does anyone have any good pointers to information on Sparc calling 
> conventions?
> I have the "Sparc Assembly Reference Manual" that comes with the big solaris
> documentation set, but I find it relatively useless.
> 
> Thanks for the help,
> 
> - Rob

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]