Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <kettenis@chello.nl>
To: msnyder@redhat.com
Cc: schwab@suse.de, gdb-patches@sources.redhat.com
Subject: Re: [PATCH/RFA] Update m68k function return value handling
Date: Tue, 04 May 2004 17:20:00 -0000	[thread overview]
Message-ID: <200405041719.i44HJqSX000782@elgar.kettenis.dyndns.org> (raw)
In-Reply-To: <4096F727.9030907@redhat.com> (message from Michael Snyder on Tue, 04 May 2004 01:51:35 +0000)

   Date: Tue, 04 May 2004 01:51:35 +0000
   From: Michael Snyder <msnyder@redhat.com>

   Mark Kettenis wrote:
   > Hi Andreas,
   > 
   > Here's a patch that converts the m68k to the new function return value
   > handling mechanism.  I tried very hard to make it possible to deal
   > with all the different m68k ABI's.  I'm pretty sure I've got it right
   > for at least OpenBSD, NetBSD and Linux.  On other systems it can't
   > really be worse than the old code. 

   Unfortunately, it can.  The problem is that when you use the new
   gdbarch_return_value_p method, print_return_value simply gives up
   on any function that returns a struct via a pointer argument
   (what we refer to as the "struct convention").  I don't know why
   it does (esp. in view of all the code you've added for determining
   eg. which register this pointer is passed in), but it does.

This has been discussed in the past.  The problem is that on almost
every target, you cannot reliably tell where the return value is
stored.  On some targets you can't even tell this when the call is
finished; I believe Andrew said this was the case on powerpc.  Anyway,
most targets, and m68k might be one of them, can tell where the
structure is stored when the function is finished.  I've promised to
look into it some time ago (since i386 is in a similar situation).
Just didn't find the time yet...

   This is especially bad for cross-m68k targets, since when
   pcc_struct_convention is used, m68k_reg_struct_return_p
   always returns false.  BTW this is wrong for gcc m68k-elf,
   so I don't understand why pcc_struct_convention is set for
   all cross targets...

Hmm.  I looked at GCC, to see what the "default" convention would be,
and config/m68k/m68k.h implicates that all structures would be
returned in static storage.  I somehow overlooked that the majority,
if not all, "embedded" targets use config/m68k/m68kemb.h, which
overrides the default in config/m68k/m68k.h to return small structures
in registers.  So it seems I've simply looked in the wrong place and
chose the wrong default.  Feel free to change it to reg_struct_return.
The Linux, OpenBSD and NetBSD targets should be immune to such a
change.  If you don't get to making the change I'll do so in a few
days.


  reply	other threads:[~2004-05-04 17:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-02 21:52 Mark Kettenis
2004-05-03 21:21 ` Andreas Schwab
2004-05-03 21:56   ` Mark Kettenis
2004-05-04  1:54     ` Michael Snyder
2004-05-04 13:13       ` Andreas Schwab
2004-05-04 17:33         ` Michael Snyder
2004-05-04  1:51 ` Michael Snyder
2004-05-04 17:20   ` Mark Kettenis [this message]
2004-05-04 20:02     ` Michael Snyder

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=200405041719.i44HJqSX000782@elgar.kettenis.dyndns.org \
    --to=kettenis@chello.nl \
    --cc=gdb-patches@sources.redhat.com \
    --cc=msnyder@redhat.com \
    --cc=schwab@suse.de \
    /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