This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
RE: sh4 abi doc
- From: "Clarke, Stephen" <stephen dot clarke at superh dot com>
- To: "Andrew Cagney" <ac131313 at redhat dot com>
- Cc: "Elena Zannoni" <ezannoni at redhat dot com>, <gdb at sources dot redhat dot com>
- Date: Thu, 26 Sep 2002 10:32:50 -0700
- Subject: RE: sh4 abi doc
> From: Andrew Cagney [mailto:ac131313@redhat.com]
> Sent: Thursday, September 26, 2002 10:19 AM
> To: Clarke, Stephen
> Cc: Elena Zannoni; gdb@sources.redhat.com
> Subject: Re: sh4 abi doc
>
>
> > "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.
>
> Suggest clarifying this. In particular how tail ``tail-padding''
> interacts with LE and BE. I think I know what this means
> (having seen
> the MIPS) but (having seen the MIPS) I also know how badly it can be
> botched :-(
Yes ... when describing how parameters are passed, we have:
"When the size of an aggregate parameter is not a multiple of
4 bytes, it is tail padded up to a multiple of 4 bytes. The value
of this padding is undefined. For little-endian targets the
padding will appear at the most significant end of the last element,
for big-endian targets the padding appears at the least significant
end of the last element."
(Here an 'element' is a 4-byte chunk of the aggregate).
But the position of the padding is not described for return
values. The intention is that return values are padded in
the same way as parameters, but you're right: it should be
stated explicitly.
Thanks,
Steve.