This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]