From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <musl-return-20408-ml=inbox.vuxu.org@lists.openwall.com>
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE
	autolearn=ham autolearn_force=no version=3.4.4
Received: from second.openwall.net (second.openwall.net [193.110.157.125])
	by inbox.vuxu.org (Postfix) with SMTP id F0FA22353E
	for <ml@inbox.vuxu.org>; Sun, 18 Feb 2024 13:37:34 +0100 (CET)
Received: (qmail 24573 invoked by uid 550); 18 Feb 2024 12:34:20 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 3427 invoked from network); 18 Feb 2024 12:12:56 -0000
Date: Sun, 18 Feb 2024 15:15:52 +0300
From: Valery Ushakov <uwe@stderr.spb.ru>
To: musl@lists.openwall.com
Message-ID: <ZdH0-P9zw0t20LXc@snips.stderr.spb.ru>
References: <349f4e17-8027-c521-eeb3-aa69e8f2b5a4@landley.net>
 <ZdEo_58yYjO6wl8y@snips.stderr.spb.ru>
 <Pine.BSM.4.64L.2402172305090.9009@herc.mirbsd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Pine.BSM.4.64L.2402172305090.9009@herc.mirbsd.org>
Subject: [musl] Re: Re: Not sure how to debug this one.

On Sat, Feb 17, 2024 at 23:09:24 +0000, Thorsten Glaser wrote:

> Valery Ushakov dixit:
> 
> >comments (*ugh*), but I *think* sigsetjmp clobbers caller's r8.
> >
> >r8 is callee saved.
> 
> Say, is there a handy list of which registers are preserved
> or clobbered across function calls like the one for syscalls
> from Linux man-pages’ syscall(2) for all arches?
> 
> I have indeed chased this same problem on unfamiliar arches
> often enough as well…

Calling conventions etc are defined in architecture's ELF psABI (ps =
processor specific, as opposed to generic (gABI)).  Though it seems
this terminology is now a bit dated.  E.g. Renesas ABI document still
has a running title of "SH-4 Generic and Specific ABI", where you can
see the echo of "generic" and "specific", but the word "processor"
never even occurs in it once.

The ELF ABI spec used to be hosted by (the old) SCO, iirc.  I'm not
sure what is the official source of truth nowadays of if even there is
one.

I would just google for "$arch psABI" and/or "$arch calling convention" :)

-uwe