Mirror of the gdb mailing list
 help / color / mirror / Atom feed
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.


  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