mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Peter Williams <>
Subject: [musl] Re: aarch64 sigsetjmp relocation truncation bug, maybe
Date: Wed, 06 Sep 2023 21:01:22 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 2665 bytes --]

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;

    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.


On Wed, 2023-09-06 at 20:46 -0400, Peter Williams wrote:
> Hello,
> 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.
> 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:
>   /home/rust/sysroot-aarch64/usr/lib/libc.a(sigsetjmp.lo): in function `sigsetjmp':
>   /home/buildozer/aports/main/musl/src/v1.2.3/src/signal/aarch64/sigsetjmp.s:7:(.text+0x0):
>     relocation truncated 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 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 possible to modify the assembler code to be able to
> handle such a situation?
> My build environment is extremely gnarly — 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.
> Thanks for any insight,
> Peter

[-- Attachment #2: Type: text/html, Size: 3748 bytes --]

  reply	other threads:[~2023-09-07  1:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-07  0:46 [musl] " Peter Williams
2023-09-07  1:01 ` Peter Williams [this message]
2023-09-07  3:08 ` Markus Wichmann
2023-09-07 12:48   ` Rich Felker
2023-09-07 13:28     ` Rich Felker
2023-09-07 19:49       ` Szabolcs Nagy
2023-09-07 14:42     ` Markus Wichmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).