From: Peter Williams <email@example.com>
Subject: [musl] Re: aarch64 sigsetjmp relocation truncation bug, maybe
Date: Wed, 06 Sep 2023 21:01:22 -0400 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
[-- 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)
... 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:
> 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
> /home/rust/sysroot-aarch64/usr/lib/libc.a(sigsetjmp.lo): in function `sigsetjmp':
> 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,
[-- Attachment #2: Type: text/html, Size: 3748 bytes --]
next prev parent 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
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).