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.3 required=5.0 tests=HTML_MESSAGE, 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 10876 invoked from network); 7 Sep 2023 01:14:49 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 7 Sep 2023 01:14:49 -0000 Received: (qmail 20416 invoked by uid 550); 7 Sep 2023 01:14:37 -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 9804 invoked from network); 7 Sep 2023 01:01:34 -0000 Message-ID: <062f8c2b1efa5b952b9e44a1953888c07a52e28e.camel@newton.cx> From: Peter Williams To: musl@lists.openwall.com Date: Wed, 06 Sep 2023 21:01:22 -0400 In-Reply-To: <1db459153e3f7be32cb469509c272977b9c2b381.camel@newton.cx> References: <1db459153e3f7be32cb469509c272977b9c2b381.camel@newton.cx> Content-Type: multipart/alternative; boundary="=-z3FBa+9Fpuija5esp4vy" User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) MIME-Version: 1.0 Subject: [musl] Re: aarch64 sigsetjmp relocation truncation bug, maybe --=-z3FBa+9Fpuija5esp4vy Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Of course, right after I send the email ... here's another piece of evidence, which I think is consistent with my interpretation below. If I simply add the following function to one of my C files: void you_gotta_be_kidding_me(int arg) { jmp_buf buf1; sigjmp_buf buf2; setjmp(buf1); sigsetjmp(buf2, arg); } ... the linker error goes away. My hypothesis is/was that code like this would encourage the linker to locate the two libc functions closer together, so that the relocation is no longer truncated. So, it appears that I at least have a workaround. Peter On Wed, 2023-09-06 at 20:46 -0400, Peter Williams wrote: > Hello, >=20 > I'm experiencing a software issue that I think maybe, might, > possibly, indicate a musl bug. I'm not at all familiar with the > issues involved, but it looks like emailing this list might be my > best bet for testing that hypothesis, so that's what I'm doing. > Please CC me on any replies as I'm not subscribed, and accept my > apologies if I'm way off base here. >=20 > The short answer is that I'm trying to link a large (~100 MB) static > executable for aarch64 and getting this error out of the binutils > linker: >=20 > /home/rust/sysroot-aarch64/usr/lib/libc.a(sigsetjmp.lo): in function `s= igsetjmp': > /home/buildozer/aports/main/musl/src/v1.2.3/src/signal/aarch64/sigsetjm= p.s:7:(.text+0x0): > relocation truncated to fit: R_AARCH64_CONDBR19 against symbol `setjm= p' > defined in .text section in /home/rust/sysroot-aarch64/usr/lib/libc.a= (setjmp.lo) >=20 > If I'm understanding correctly, the complaint is that a=C2=A0branch in > sigsetjmp that invokes setjmp=C2=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? >=20 > My build environment is extremely gnarly =E2=80=94 I am running my build > tools inside a cross-compiling Alpine Linux chroot that in turn runs > inside an Ubuntu Docker container. (You don't want to know.) I can > provide more details if needed, as well as a script that leads up to > the error on my system, if you have CPU time to burn on the Docker > container build. But since the error seems to be localized within my > aarch64 "libc.a", I'm hopeful that maybe this funky environment > doesn't actually affect the core situation here. As you might see in > the output above, I'm using musl 1.2.3. >=20 > Thanks for any insight, >=20 > Peter >=20 --=-z3FBa+9Fpuija5esp4vy Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Of course, right after I send the email ... here'= s another piece of evidence, which I think is consistent with my interpreta= tion below.

If I simply add the following function= to one of my C files:

void you_gotta_be_kidding_m=
e(int arg)
{
    jmp_buf buf1;
    sigjmp_buf=
 buf2;

    setjmp(buf1);
    sigsetjmp(b=
uf2, arg);
}

... the linker error goes a= way. My hypothesis is/was that code like this would encourage the linker to= locate the two libc functions closer together, so that the relocation is n= o longer truncated. So, it appears that I at least have a workaround.
=

Peter

On Wed, 2023-09-06 at 20= :46 -0400, Peter Williams wrote:
Hello= ,

I'm experiencing a software issue that I think m= aybe, might, possibly, indicate a musl bug. I'm not at all familiar with th= e issues involved, but it looks like emailing this list might be my best be= t for testing that hypothesis, so that's what I'm doing. Please CC me on an= y replies as I'm not subscribed, and accept my apologies if I'm way off bas= e here.

The short answer is that I'm trying to lin= k a large (~100 MB) static executable for aarch64 and getting this error ou= t of the binutils linker:

  /home/rust/sysroot-aar=
ch64/usr/lib/libc.a(sigsetjmp.lo): in function `sigsetjmp':
  /ho=
me/buildozer/aports/main/musl/src/v1.2.3/src/signal/aarch64/sigsetjmp.s:7:(=
.text+0x0):
    relocation truncated to fit: R_AARCH64_CONDBR19 a=
gainst symbol `setjmp'
    defined in .text section in /home/rust=
/sysroot-aarch64/usr/lib/libc.a(setjmp.lo)

If I'm = understanding correctly, the complaint is that a branch in sigsetjmp that invokes setjmp is 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 pos= sible to modify the assembler code to be able to handle such a situation?

My build environment is extremely gnarly =E2=80=94 = I am running my build tools inside a cross-compiling Alpine Linux chroot th= at in turn runs inside an Ubuntu Docker container. (You don't want to know.= ) I can provide more details if needed, as well as a script that leads up t= o the error on my system, if you have CPU time to burn on the Docker contai= ner build. But since the error seems to be localized within my aarch64 "lib= c.a", I'm hopeful that maybe this funky environment doesn't actually affect= the core situation here. As you might see in the output above, I'm using m= usl 1.2.3.

Thanks for any insight,

<= /div>
Peter


--=-z3FBa+9Fpuija5esp4vy--