  /home/rust/sysroot-aarch64/usr/lib/libc.a(sigsetjmp.lo): in functi=
on `sigsetjmp':

  /home/buildozer/aports/main/musl/src/v1.2.3/src=
/signal/aarch64/sigsetjmp.s:7:(.text+0x0):

    relocation truncat=
ed to fit: R_AARCH64_CONDBR19 against 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 th=
at a branch in sigsetjmp that invokes setjmp is too far away from the definition of setjmp. My very handwavey ide=
a 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 abl=
e to handle such a situation?

My build environment=
 is extremely gnarly =E2=80=94 I am running my build tools inside a cross-c=
ompiling Alpine Linux chroot that in turn runs inside an Ubuntu Docker cont=
ainer. (You don't want to know.) I can provide more details if needed, as w=
ell as a script that leads up to the error on my system, if you have CPU ti=
me to burn on the Docker container build. But since the error seems to be l=
ocalized within my aarch64 "libc.a", I'm hopeful that maybe this funky envi=
ronment doesn't actually affect the core situation here. As you might see i=
n the output above, I'm using musl 1.2.3.

Thanks f=
or any insight,

Peter

--=-GIj2GCC9Y740msRTgxAO--

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