From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21197 invoked by alias); 26 Sep 2002 17:33:38 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 21189 invoked from network); 26 Sep 2002 17:33:36 -0000 Received: from unknown (HELO smtp.superh.com) (65.219.1.204) by sources.redhat.com with SMTP; 26 Sep 2002 17:33:36 -0000 Received: from sh-us-ex01.us.w2k.superh.com (sh-us-ex01.us.superh.com [192.168.4.40]) by smtp.superh.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8QHPdN11443; Thu, 26 Sep 2002 10:25:39 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: sh4 abi doc X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 26 Sep 2002 10:33:00 -0000 Message-ID: <287E4644B5249D449C56FA5409A874AE03EFBA@sh-us-ex01.us.w2k.superh.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Clarke, Stephen" To: "Andrew Cagney" Cc: "Elena Zannoni" , X-SW-Source: 2002-09/txt/msg00439.txt.bz2 > From: Andrew Cagney [mailto:ac131313@redhat.com]=20 > Sent: Thursday, September 26, 2002 10:19 AM > To: Clarke, Stephen > Cc: Elena Zannoni; gdb@sources.redhat.com > Subject: Re: sh4 abi doc >=20 >=20 > > "When an aggregate type is returned in R0 and R1, R0=20 > contains the first > > four bytes of the aggregate, and R1 contains the remainder.=20 > 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. >=20 > Suggest clarifying this. In particular how tail ``tail-padding''=20 > interacts with LE and BE. I think I know what this means=20 > (having seen=20 > the MIPS) but (having seen the MIPS) I also know how badly it can be=20 > 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.