From: Elena Zannoni <ezannoni@redhat.com>
To: "Clarke, Stephen" <stephen.clarke@superh.com>
Cc: "Elena Zannoni" <ezannoni@redhat.com>, <gdb@sources.redhat.com>
Subject: RE: sh4 abi doc
Date: Thu, 26 Sep 2002 10:46:00 -0000 [thread overview]
Message-ID: <15763.18230.7231.652861@localhost.redhat.com> (raw)
In-Reply-To: <287E4644B5249D449C56FA5409A874AE03EFB9@sh-us-ex01.us.w2k.superh.com>
Clarke, Stephen writes:
>
>
> > From: Elena Zannoni [mailto:ezannoni@redhat.com]
> > Sent: Thursday, September 26, 2002 9:51 AM
>
> > in the meantime, do you know what is the official rule for returning
> > results on the stack, instead of in the return register?
> > Seems that gdb and gcc are disagreeing on this.
> > Gdb expects structs to be returned on the stack if their size is > 1.
>
> Here's what we have:
>
> "Aggregate types not bigger than 8 bytes that have the same size and
> alignment as one of the integer scalar types are returned in the same
> registers as the integer type they match.
>
> "For example, a 2-byte aligned structure with size 2 bytes has the
> same size and alignment as a short int, and will be returned in R0.
> A 4-byte aligned structure with size 8 bytes has the same size and
> alignment as a long long int, and will be returned in R0 and R1.
>
> "When an aggregate type is returned in R0 and R1, R0 contains the first
> four bytes of the aggregate, and R1 contains the remainder. If the size
> of the aggregate type is not a multiple of 4 bytes, the aggregate is
> tail-padded up to a multiple of 4 bytes. The value of the padding is
> undefined.
>
> "All other aggregate types are returned by address. The caller function
> passes the address of an area large enough to hold the aggregate value
> in R2. The called function stores the result in this location."
>
Ah, so gdb is wrong. The cutoff is 8 bytes.
> I hope that makes sense, it was difficult to describe both clearly and
> accurately!
>
yes. except for BE/LE differences. But you clarified that already.
> Actually, the SH-4 ABI documentation that Red Hat supplies with
> the gnupro tools says the same thing in fewer words, but (IMO)
> not as clearly.
>
Doh, I should have thought about that.
Elena
> Steve.
next prev parent reply other threads:[~2002-09-26 17:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-26 10:10 Clarke, Stephen
2002-09-26 10:18 ` Andrew Cagney
2002-09-26 10:46 ` Elena Zannoni [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-09-26 11:47 Clarke, Stephen
2002-09-26 12:45 ` Elena Zannoni
2002-09-26 12:54 ` Andrew Cagney
2002-09-26 10:33 Clarke, Stephen
2002-09-26 9:17 Clarke, Stephen
2002-09-26 9:54 ` Elena Zannoni
2002-09-26 8:21 Elena Zannoni
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=15763.18230.7231.652861@localhost.redhat.com \
--to=ezannoni@redhat.com \
--cc=gdb@sources.redhat.com \
--cc=stephen.clarke@superh.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