From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15104 invoked from network); 7 Sep 2023 03:08:29 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 7 Sep 2023 03:08:29 -0000 Received: (qmail 23841 invoked by uid 550); 7 Sep 2023 03:08:26 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 23806 invoked from network); 7 Sep 2023 03:08:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1694056094; x=1694660894; i=nullplan@gmx.net; bh=K7M+44eCC9YyUN8Wjgaj1XBDm9NtjZ1qiKDg6SXfEvw=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=Qzj7EKRGCVe18oFwDUFTvQY/n3j+qn31eArs44ik5qYW+STmtTTDWQl6ZnEQj4QuxQ0jRM8 zfTkHE3LMuf9cyvsJ9sB9/seZHFmY9gA5jqgaGiOh/Xk740WHHiTz//BnvoPjWBP/AbJtd1UL rkYKHZAbxlzaD7itjR/R4EvudH1gXif4JmTlhQGICeYO+kY62J1xX7UXdM4+DiTMNUHCvUwY9 2BwJPLJYWejWjvZkZ6jbMtBl/SRuW3RruXrQxHtUkwtcNg4qf/3qfZrdgtk4xqRjluunLNne0 MovzKUNdSsHc0aCpwhDsueUWJkV4aAT7P3NJc5T7kRIckjUI65QA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Thu, 7 Sep 2023 05:08:13 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: References: <1db459153e3f7be32cb469509c272977b9c2b381.camel@newton.cx> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="FDPiRWCTPHY74CP1" Content-Disposition: inline In-Reply-To: <1db459153e3f7be32cb469509c272977b9c2b381.camel@newton.cx> X-Provags-ID: V03:K1:U8X+Tst4MpTrtZIwV+8iFQoMdOTZo3xws3fl9NvX4FXcxLlWWW6 st9LqmilVKXhu+DPMNsuqTt8RtF0fMFKrnhbX1JcerSwPH6Q9N4eGgNQMlOl8L6raaRjgXv 9HpsoCyAigSwXSXPgKmi1RKrokzf7P6h6HI1QbSDrID8NnMyqmGXRLpOC+JwTq7HvMiH8Qn D9tLKXma0WziBfiLce1bQ== UI-OutboundReport: notjunk:1;M01:P0:f3WUMK1UD6c=;wgwIC6gYUkcglcroR+X9Vl/ff70 bjYXWI4Wz364/z1donjGRvggdv2qQTqqX0p0ClKmc1Q7Lh09lI1Wy7u79XFUDZcR3t1nDfeQY QScZ/tFgjlrwurv4ciTXlqcEsKWXDwGjvWkWsD2Cp2phnMrdlWQcq7ZRGGaTnQv22vsmj5/lr eJbc/DOSHw+ZDbEv+WFaewCCBZWKZIJNXHe5CvwN50CsSkS9ssZ8pdhsIrZt9fYD5qhxK0OtY AWoAdV3JKTC9CsSoONHH9QQxFxPBJYIIUjFmroBuqPFk09iKeMMZIlO8CSIc11KvRC5OemYn2 JVSs7LYaHpkrUavowpsaIX1wpqgQrOAVMSOGCrs7/uAdVTk7KE9d5vrxTQyhACaqQBbaIKdWO KuawJmhVhcDIksDSpjVvF6YdSEFzLf2DEjwXjRjv/NpPP4i0RW2ZTNi4M6GoTZwrrFpWpHjif fqjj6/eeMBGCWrpN50qDUssO7cIXWvK4iNAx6MlYIXBZR6qgLmUIRiM51UU4Eo+NTYh3wqH3M +4Zh1nw9RA4uaZGriQkkUXPmv/a6IhRWUSAw45T4OqXeEEW/yoIra9KBY620bQKC32TAe8Xpr w1Eajy697gJm1OGXO71SVUuy7vbbKECjQO9JmK6DVWuqUqpTQiLcarL9vaLHE+xMlNnfvlD09 EjuJikuBKHyIO9xhfmHd4cAZstJdetTXBVUuXv13mM8DbShtWsUbA3KjTuaOjJNNtw6KDBDeH TvFBZGe2eoMV/WpJ4Za6XbuvYbZGjNDzFrxgM2VVNuHApZyp5cpwhXIrtmfGcbp5H87sZsi9Y 0YJjI2BhhqvHdFwW37hnvMF21JQVMf2kdq9tFgVf1EGH9SJpz4tNRDP5dr0ALxHN3NeyvFzNk IHZroTX1UEmyBrkgIR5xP4/pOZISefFRQDLMhvwnawyyYubPxiWGJrrEpMg8QUHmUWeJkRCkq LBcq5LPQapRcb3GpMCxY2og73TM= Subject: Re: [musl] aarch64 sigsetjmp relocation truncation bug, maybe --FDPiRWCTPHY74CP1 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am Wed, Sep 06, 2023 at 08:46:32PM -0400 schrieb Peter Williams: > If I'm understanding correctly, the complaint is that a=A0branch in > sigsetjmp that invokes setjmp=A0is too far away from the definition of > setjmp. My very handwavey idea is that maybe for some reason my program > is causing the linker to want to locate setjmp() and sigsetjmp() really > far away from each other. If that's right, perhaps it would be possible > to modify the assembler code to be able to handle such a situation? I'm guessing the same. Pretty much all architectures have shorter conditional than unconditional branches. That is why branches to other files (technically to other sections) should always be unconditional. I am attaching a simple patch that should help with the situation. Ciao, Markus --FDPiRWCTPHY74CP1 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0001-Make-branch-to-external-symbol-unconditional.patch" Content-Transfer-Encoding: quoted-printable =46rom dd227e22a5337d54e1cb0838410bca6672c76c43 Mon Sep 17 00:00:00 2001 From: Markus Wichmann Date: Thu, 7 Sep 2023 05:01:23 +0200 Subject: [PATCH] Make branch to external symbol unconditional. Conditional branches have a shorter branch length than unconditional ones, and almost all ABIs require unconditional branches to external symbols. Otherwise linkers may create broken binaries. =2D-- src/signal/aarch64/sigsetjmp.s | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/signal/aarch64/sigsetjmp.s b/src/signal/aarch64/sigsetjmp= .s index 75910c43..9a28e395 100644 =2D-- a/src/signal/aarch64/sigsetjmp.s +++ b/src/signal/aarch64/sigsetjmp.s @@ -4,7 +4,7 @@ .type __sigsetjmp,%function sigsetjmp: __sigsetjmp: - cbz x1,setjmp + cbz x1,1f str x30,[x0,#176] str x19,[x0,#176+8+8] @@ -19,3 +19,5 @@ __sigsetjmp: .hidden __sigsetjmp_tail b __sigsetjmp_tail + +1: b setjmp =2D- 2.39.2 --FDPiRWCTPHY74CP1--