From: Mark Kettenis <kettenis@chello.nl>
To: gdb@sources.redhat.com
Subject: [RFC] Struct return values
Date: Fri, 09 Jan 2004 16:22:00 -0000 [thread overview]
Message-ID: <200401091622.i09GMRVn000591@elgar.kettenis.dyndns.org> (raw)
Recently Andrew did some work on structure return values. The result
was that GDB now refuses to make a function return, that returns a
struct accoriding to the "struct value" convention. The reasoning
behind this is that in general, we can't determine the address of the
bit of memory where we're supposed to return the value if we're in the
middle of such a function. However, it turns out that with 32-bit
SPARC, we can find out. The SPARC stack frames have a reserved slot
for this address. Should we allow returning in this case?
Furthermore, the testsuite contains the following comment:
# The struct return case. Since any modification
# would be by reference, and that can't happen, the
# value should be unmodified and hence Z is expected.
# Is this a reasonable assumption?
I think the answer to the question is "no". It's perfectly allowed
for the caller to provide a bit of scratch memory for the return
value, and copy the contents of this bit of memory to the variable
after the callee returns. Now if we return from a random point in the
callee, the contents of the scratch memory will be undetermined, and
some random bytes will be copied into the variable. This happens for
code generated by the Sun compiler. A way to fix this, is to make
sure that GDB stops immediately after we return from the callee. Is
there an easy way to achieve this? Otherwise, I think we should
refrain from checking the value in this case.
Comments?
Mark
next reply other threads:[~2004-01-09 16:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-09 16:22 Mark Kettenis [this message]
2004-01-09 20:05 ` Andrew Cagney
2004-01-09 23:47 ` Mark Kettenis
2004-01-11 15:58 ` Andrew Cagney
2004-01-17 19:08 ` Andrew Cagney
2004-01-18 15:20 ` Mark Kettenis
2004-01-18 16:31 ` Andrew Cagney
2004-01-18 22:13 ` Mark Kettenis
2004-01-22 14:20 ` Andrew Cagney
2004-01-22 21:52 ` Mark Kettenis
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=200401091622.i09GMRVn000591@elgar.kettenis.dyndns.org \
--to=kettenis@chello.nl \
--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