This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
REG_STRUCT_HAS_ADDR
- From: Mark Kettenis <kettenis at chello dot nl>
- To: gdb at sources dot redhat dot com
- Cc: ac131313 at redhat dot com, dan at debian dot org
- Date: Sun, 7 Sep 2003 00:06:02 +0200 (CEST)
- Subject: REG_STRUCT_HAS_ADDR
By defining REG_STRUCT_HAS_ADDR, a target can indicate that structure
and union arguments are passed by reference instead of by value.
While working on the SPARC target, I read the following comment in
infcall.c:call_function_by_hand:
if (REG_STRUCT_HAS_ADDR_P ())
{
...
if (STACK_ALIGN_P ())
/* MVS 11/22/96: I think at least some of this
stack_align code is really broken. Better to let
PUSH_ARGUMENTS adjust the stack in a target-defined
manner. */
aligned_len = STACK_ALIGN (len);
else
aligned_len = len;
I totally agree with Michael here, so I decided that the new SPARC
stuff shouldn't define REG_STRUCT_HAS_ADDR, and implement the whole
thing in its PUSH_DUMMY_CALL function.
Unfortunately this breaks debugging with stabs, since stabsread.c uses
the same REG_STRUCT_HAS_ADDR to see if a function argument is passed
by value or by reference. I think we really want to get rid of the
broken code in infcall.c in the long run. Therefore I looked for a
way to disable it for "modern" targets, i.e. targets that define
PUSH_DUMMY_CALL as opposed to the old PUSH_DUMMY_FRAME & friends.
Looking at the code I found that the following targets (besides SPARC)
are using REG_STRUCT_HAS_ADDR:
* MIPS EABI (32-bit and 64-bit)
* CRIS
* HP PA
* MN10300
(MCore defines REG_STRUCT_HAS_ADDR, but always returns 0, soo it
doesn't actually use the feature.)
Of these targets, only MIPS EABI uses the new PUSH_DUMMY_CALL.
Looking at mips_eabi_push_dummy_call, it seems as if it already
handles tries to pass the larger structures by reference. That would
mean that it is indeed possible to change the
if (REG_STRUCT_HAS_ADDR_P ())
into
if (REG_STRUCT_HAS_ADDR_P ()
&& !gdbarch_push_dummy_call_p (current_gdbarch))
and be done with it. I'm a little afraid however, that the MIPS code
in mips_eabi_push_dummy_call has never been tested, since in the
current situation it's dead code. I don't have access to a MIPS
machine myself, is there anyone who could test the attached patch for
me on MIPS EABI? Look for any regressions in gdb.base/call-ar-st.exp,
in particular:
FAIL: gdb.base/call-ar-st.exp: step into print_long_arg_list
Thanks,
Mark
Index: infcall.c
===================================================================
RCS file: /cvs/src/src/gdb/infcall.c,v
retrieving revision 1.24
diff -u -p -r1.24 infcall.c
--- infcall.c 28 Aug 2003 02:53:08 -0000 1.24
+++ infcall.c 6 Sep 2003 22:02:21 -0000
@@ -661,7 +661,8 @@ You must use a pointer to function type
}
}
- if (REG_STRUCT_HAS_ADDR_P ())
+ if (REG_STRUCT_HAS_ADDR_P ()
+ && !gdbarch_push_dummy_call_p (current_gdbcarch))
{
int i;
/* This is a machine like the sparc, where we may need to pass a