Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <kettenis@chello.nl>
To: gdb@sources.redhat.com
Cc: ac131313@redhat.com, dan@debian.org
Subject: REG_STRUCT_HAS_ADDR
Date: Sat, 06 Sep 2003 22:06:00 -0000	[thread overview]
Message-ID: <200309062206.h86M62no012596@elgar.kettenis.dyndns.org> (raw)

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




             reply	other threads:[~2003-09-06 22:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-06 22:06 Mark Kettenis [this message]
2003-09-08 18:43 ` REG_STRUCT_HAS_ADDR Andrew Cagney
2003-09-13 14:25   ` REG_STRUCT_HAS_ADDR Mark Kettenis
2003-09-13 15:01     ` REG_STRUCT_HAS_ADDR Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200309062206.h86M62no012596@elgar.kettenis.dyndns.org \
    --to=kettenis@chello.nl \
    --cc=ac131313@redhat.com \
    --cc=dan@debian.org \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox