Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch
Subject: Re: Calling conventions (particularly 32-bit ARM)
Date: Fri, 10 Jan 2025 18:39:12 +0100
Organization: A noiseless patient Spider
Lines: 127
Message-ID: <vlrm00$5nlr$1@dont-email.me>
References: <vlgngv$1ks4a$1@dont-email.me>
 <4903307dfcce354508c9fc016a4c1ea1@www.novabbs.org>
 <jwv34htql17.fsf-monnier+comp.arch@gnu.org>
 <2025Jan8.230846@mips.complang.tuwien.ac.at>
 <jwvr05cq4tx.fsf-monnier+comp.arch@gnu.org>
 <2025Jan9.082357@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 10 Jan 2025 18:39:13 +0100 (CET)
Injection-Info: dont-email.me; posting-host="38538fe9dc1eebef7a150b4b38221e70";
	logging-data="188091"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX198Ek3V6DInusIP/SLaG5/2FPjhBZ++Tdo="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:t2oCm1oe/3fAgwci7AGPpDHT2Y0=
Content-Language: en-GB
In-Reply-To: <2025Jan9.082357@mips.complang.tuwien.ac.at>
Bytes: 7661

On 09/01/2025 08:23, Anton Ertl wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> [Someone wrote:]
>>> ABI calling conventions tend to be designed to support at least C,
>>> including varargs and often also tolerant of differences between the
>>> number of arguments in the caller and callee.

Why should an ABI be tolerant of such differences?  In C, calling a 
function with an unexpected number (or type) of arguments has always 
been undefined behaviour, and always been something that programmers 
have strived to avoid.  For variadic functions (including old 
pre-standard functions), the code does not declare the number or types 
of arguments, but you still have to match up the caller and callee. 
Call printf() with a mismatch between the format string and the 
arguments, and you can expect nasal daemons.

I am all in favour of things like ABI's not intentionally making things 
significantly worse - no one wants a system that turns code bugs into 
something like an exploitable security hole from stack corruption.

However, I see no good reason to try to make things "work" with broken 
code.  An ABI should be designed with an emphasis on being efficient for 
correct code - not for being tolerant of hopelessly incorrect code.

C /does/ require support for variadic functions, so that has to be in 
any ABI usable with C.

>>
>> I can agree that it's important to support those use-cases (varargs
>> obviously, mismatched arg numbers less so),
> 
> You are head of a group of people who design a new architecture (say,
> it's 2010 and you design ARM A64, or it's 2014 and you design RISC-V).
> Your ABI designer comes to you and tells you that his life would be
> easier if it was ok that programs with mismatched arguments don't need
> to work.  Would you tell him that they don't need to work?
> 

I would, yes.  The efficiency of good code should not suffer because of 
the existence of bad code.

I'd still try to avoid making results that are more dangerous than 
necessary.  Maybe you do that by making it clear to compiler writers 
that the ABI should not be used with a compiler that supports implicit 
function declarations - that would block most risky or broken code at 
compile time.  Perhaps you say that object files using this ABI need 
extra sections holding basic information about the function's parameters 
with its definition, and about the arguments when calling the function, 
and encouraging linkers to check for mismatches.  There would surely be 
cases where you can't check - casts of function pointer types, dynamic 
linking, etc., - but you would again eliminate a large proportion of errors.

> If yes, a few years down the road your prospective customers have to
> decide whether to go for your newfangled architecture or one of the
> established ones.  They learn that a number of programs work
> everywhere else, but not on your architecture.  How many of them will
> be placated by your reasoning that these programs are not strictly
> confoming standard programs?  How many will be alarmed by your
> admission that you find it ok that you find it ok that such programs
> don't work on your architecture?  After all, hardly any program is a
> strictly conforming standard program.

How many people actually want to use code where some functions are 
called with an incorrect number of parameters?  Such code is /broken/. 
If it ever gave results that the original users were happy with, it is 
by luck - no matter what ABI you have for your new architecture and new 
tools, it's pure luck whether things work or not in any sense.

So the best you can do for your prospective customers is tell them that 
you prioritise the results for correct code and help them with tools to 
find mistakes in their ancient broken code.

Accepting the unfortunate reality that most code of a significant size 
has /some/ bugs in it does not mean it is a good idea to reduce the 
efficiency of good code in a vain attempt at replicating the luck of old 
undefined behaviour on other platforms!  That is especially true for a 
class of error that only exists due to very sloppy development 
practices, and should be identifiable by automatic linting and static 
checking.

It never ceases to disappoint me how lax C is at fixing things that were 
design flaws from day one of the language.  Backwards compatibility is 
very important, but allowing such crappy coding to be accepted simply 
encourages more people to write crappy code for longer.  C compilers are 
even worse, as they usually support crappy code for longer than the C 
standards.  Implicit function declarations were removed from the C 
language in C99, and non-prototype declarations were made obsolescent in 
C90, yet not removed from the language until C23.

> 
>> only sloppy ancient C calls
>> functions without proper declarations)
> 
> You find it ok to design a calling convention such that ancient C
> programs do not work?
> 

My original post was about an ABI for microcontroller programming.  For 
that use, my answer is a definite "yes".

For more general use, my answer would also be "yes" for a new 
architecture and ABI.  I don't see why anyone should pander to ancient 
sloppy code.  If there really is a significant body of C code that does 
not use function prototypes, and that code really is still useful and 
relevant, then it should not be much of a challenge to write a little 
utility program that converts the old code to something more modern. 
Maybe clang-format can already do that.

> What benefit do you expect from such a calling convention?  To allow
> to use registers as arguments (and not callee-saved) that would
> otherwise be preferably used as callee-saved registers?
> 

That sounds like a benefit to me.

> 
>> even if it comes at the cost of
>> using different calling conventions for the two cases.
> 
> That would mean that you find it ok that existing programs that use
> vararg functions like printf but do not declare them before use don't
> work on your newfangled architecture.

I would certainly be OK with that.  I can understand that some people 
will disagree, but I really think there are better ways to handle old 
and/or broken code.