This is the mail archive of the gdb-patches@sourceware.org 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]
Other format: [Raw text]

Re: Ada gdb failures on hppa


> Date: Sat, 31 Dec 2005 11:04:44 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Sat, Dec 31, 2005 at 10:56:17AM +0400, Joel Brobecker wrote:
> > > I wonder what would happen is we changed the STRUCT_CONVENTION into
> > > RETURN_VALUE_ABI_RETURNS_ADDRESS... I'll experiment quickly (have to
> > > run soon) but I have suspicions that messy things might happen :-/.
> > 
> > I won't have time to test the following simple-minded patch, but it
> > seems to be doing the trick for this specific case. It basically looks
> > like the return_value methods of hppa needs to be enhanced to know how
> > to retrive values returned by address...
> > 
> > I'll finish having a look next week if I have time, but don't hesitate
> > to take over if you want. I think the hppa64 part will be identical,
> > so perhaps isolating this in a function and then call this new function
> > from both hppa32 and hppa64 return_value methods will fix the problem
> > for both ABIs.
> 
> It's pretty unlikely that this change is safe - it's likely to work for
> simple functions, but not for more complex ones.  Do you have an ABI
> document to back this up?  Specifically these comments in defs.h:
> 
>   /* Like the "struct return convention" above, but where the ABI
>      guarantees that the called function stores the address at which
>      the value being returned is stored in a well-defined location,
>      such as a register or memory slot in the stack frame.  Don't use
>      this if the ABI doesn't explicitly guarantees this.  */
>   RETURN_VALUE_ABI_RETURNS_ADDRESS,
>   /* Like the "struct return convention" above, but where the ABI
>      guarantees that the address at which the value being returned is
>      stored will be available in a well-defined location, such as a
>      register or memory slot in the stack frame.  Don't use this if
>      the ABI doesn't explicitly guarantees this.  */
>   RETURN_VALUE_ABI_PRESERVES_ADDRESS,
> 

The closest thing to an hppa ABI is the "32-bit PA-RISC Run-time
Architecture Document".  It explicitly says that: "The caller may not
assume that the result's address is still in GR28 on return from the
function."  So that places hppa firmly into the
RETURN_VALUE_STRUCT_CONVENTION category.

So Joel, sadly there is no way to fix this.  I guess the particular
test should be XFAIL'ed for hppa-*-* and other targets that use
RETURN_VALUE_STRUCT_CONVENTION.

> [Mark, you added these.  Could you explain the difference between the
> two?  There's no target using RETURN_VALUE_ABI_PRESERVES_ADDRESS, and
> I completely don't understand what the difference is supposed to be.
> They're always handled the same way, too.]

The distinction is that RETURN_VALUE_ABI_RETURNS_ADDRESS address
guarantees that the address is available just after we returned from a
function, whereas RETURN_VALUE_ABI_PRESERVES_ADDRESS guarantees that
that address will be available even if we're somewhere in the middle
of the function (which implies that the address is the same as the
address being passed in).  This is mainly for the benefit of
implementing "return".  The (32-bit) sparc allows
RETURN_VALUE_ABI_PRESERVES_ADDRESS but I guess I really implemented
it.

The wording could be improved I think; proposals for better wording
are welcome!

Mark


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