From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by sourceware.org (Postfix) with ESMTPS id 2FAAF3858D3C for ; Mon, 10 Jan 2022 13:28:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2FAAF3858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sandoe.co.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=sandoe.co.uk Received: (qmail 74796 invoked from network); 10 Jan 2022 13:27:58 -0000 X-APM-Out-ID: 16418212787479 X-APM-Authkey: 257869/1(257869/1) 5 Received: from unknown (HELO ?192.168.1.214?) (81.138.1.83) by smtp002.apm-internet.net with SMTP; 10 Jan 2022 13:27:58 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Subject: Re: Help with an ABI peculiarity From: Iain Sandoe In-Reply-To: <877db80yuv.fsf@oldenburg.str.redhat.com> Date: Mon, 10 Jan 2022 13:27:58 +0000 Cc: GCC Development Content-Transfer-Encoding: quoted-printable Message-Id: <17BE25E8-4BE6-4F38-AFDE-1DFD28417D5C@sandoe.co.uk> References: <6238c748-c7f3-159b-0464-2175eb6d1b0a@gmail.com> <877db80yuv.fsf@oldenburg.str.redhat.com> To: Florian Weimer X-Mailer: Apple Mail (2.3445.104.21) X-Spam-Status: No, score=-8.8 required=5.0 tests=BAYES_00, KAM_COUK, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2022 13:28:01 -0000 Hi Florian, > On 10 Jan 2022, at 08:38, Florian Weimer wrote: >=20 > * Jeff Law via Gcc: >=20 >> Most targets these days use registers for parameter passing and >> obviously we can run out of registers on all of them. The key >> property is the size/alignment of the argument differs depending on = if >> it's pass in a register (get promoted) or passed in memory (not >> promoted). I'm not immediately aware of another ABI with that >> feature. Though I haven't really gone looking. >=20 > I think what AArch64 Darwin does is not compatible with a GCC = extension > that allows calling functions defined with a prototype without it (for > pre-ISO-C compatibility). AFAIU the implementation: In the case that a call is built and no prototype is available, the = assumption is that all parms are named. The promotion is then done according to the C promotion rules. [for the number of args that can be passed in int regs] the callee will = happen to observe the same rules in this case. It will, however, break once we overflow the number of int regs.. :/ =3D=3D=3D=3D The case that is fundamentally broken from scratch is of a variadic = function called without a prototype - since the aarch64-darwin ABI places unnamed parms differently. So that the absence of a prototype causes us to place all args as if = they were named. =3D=3D=3D=3D Wmissing-prototype Wstrict-prototypes would wisely be promoted to errors for this platform, (the ABI is obviously not up for change, since it=E2=80=99s already on = millions of devices). > Given that, anyone defining an ABI in > parallel with a GCC implementation probably has paused, reconsidered > what they were doing, My guess is that this step was omitted - i.e. the port was designed in = the LLVM framework. I can raise a query with the ABI owners, I guess. > and adjusted the ABI for K&R compatibility. FWIW, we bootstrap sucessfully including the K&R code in intl/ Given we have 8 int regs available, probably many calls will work ..=20 =3D=3D=3D=3D As of now, I must assume that what is broken by the cases above will = remain broken, and I just need to find a way to implement the cases that will = work (i.e. when proper prototypes are available) thanks Iain