From: Michael Snyder <msnyder@redhat.com>
To: Mark Kettenis <kettenis@chello.nl>
Cc: cagney@gnu.org, gdb-patches@sources.redhat.com
Subject: Re: [PATCH/RFC/RFA] Print in-memory struct return values
Date: Wed, 12 May 2004 17:47:00 -0000 [thread overview]
Message-ID: <40A26312.7060109@redhat.com> (raw)
In-Reply-To: <200405081958.i48Jw3dm000345@elgar.kettenis.dyndns.org>
Mark Kettenis wrote:
Date: Fri, 07 May 2004 18:35:28 -0400
From: Andrew Cagney <cagney@gnu.org>
> The current GDB doesn't print the return value when using `finish' for
> functions return structures that are not returned in registers. Note
> that this is a regression from GDB 6.0 for many systems. Anyway, the
> attached patch provides a way to fix this, and adds the necessary
> support to the i386 target.
>
> If there are no comments, I'll check this in in a few days. Eli, is
> the doc bit OK?
Why not add another member to `enum return_value_convention' so that
return_value() can directly differentate between these two cases?
I called the new member RETURN_VALUE_ADDRESS_CONVENTION. I'm not
really satisfied with that name, but I couldn't think of something
better.
RETURN_VALUE_BY_REFERENCE? This is, in effect, an invisible
reference variable.
The implementation is fairly simple, but I took the
opportunity to re-arrange the code such that the legacy stuff is
separated out, that's why the patch looks a bit more invasive.
Andrew, do you have any objections?
While implementing this stuff, it occured to me that the return value
of gdbarch_return_value() really should be a set of bit flags instead
of an enum. We should have flags that indicate:
* Whether GDB should allocate some memory to store the return value.
* Whether the location of the return value is known when we've just
returned from a function.
* Whether the location of the return value is known when we're
currently executing a function.
I think the ABI's I've seen thus far cover at least six of the eight
posible combinations. Thoughts? I'd like to check in the attached
patch regardless of what we decide.
Mark
next prev parent reply other threads:[~2004-05-12 17:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-07 17:07 Mark Kettenis
2004-05-07 22:35 ` Andrew Cagney
2004-05-07 23:10 ` Mark Kettenis
2004-05-08 19:58 ` Mark Kettenis
2004-05-12 17:47 ` Michael Snyder [this message]
2004-05-15 21:26 ` Mark Kettenis
2004-05-15 22:12 ` Andreas Schwab
2004-05-16 10:28 ` Mark Kettenis
[not found] ` <200405081958.i48JwlUU000353@elgar.kettenis.dyndns.org>
[not found] ` <409D4216.4050401@gnu.org>
[not found] ` <200405082101.i48L1NUK000503@elgar.kettenis.dyndns.org>
2004-05-08 21:14 ` Andrew Cagney
2004-05-08 23:02 ` Mark Kettenis
2004-05-09 13:59 ` Andrew Cagney
2004-05-09 14:03 ` Mark Kettenis
2004-05-11 23:53 ` 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=40A26312.7060109@redhat.com \
--to=msnyder@redhat.com \
--cc=cagney@gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=kettenis@chello.nl \
/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