mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Peter Williams <peter@newton.cx>
To: musl@lists.openwall.com
Subject: [musl] aarch64 sigsetjmp relocation truncation bug, maybe
Date: Wed, 06 Sep 2023 20:46:32 -0400	[thread overview]
Message-ID: <1db459153e3f7be32cb469509c272977b9c2b381.camel@newton.cx> (raw)

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

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: 2516 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 Peter Williams [this message]
2023-09-07  1:01 ` [musl] " Peter Williams
2023-09-07  3:08 ` [musl] " 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=1db459153e3f7be32cb469509c272977b9c2b381.camel@newton.cx \
    --to=peter@newton.cx \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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

	https://git.vuxu.org/mirror/musl/

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).