From: Szabolcs Nagy <firstname.lastname@example.org>
To: Rich Felker <email@example.com>
Cc: firstname.lastname@example.org, Peter Williams <email@example.com>
Subject: Re: [musl] aarch64 sigsetjmp relocation truncation bug, maybe
Date: Thu, 7 Sep 2023 21:49:35 +0200 [thread overview]
Message-ID: <20230907194935.GG3448312@port70.net> (raw)
* Rich Felker <firstname.lastname@example.org> [2023-09-07 09:28:52 -0400]:
> On Thu, Sep 07, 2023 at 08:48:28AM -0400, Rich Felker wrote:
> > On Thu, Sep 07, 2023 at 05:08:13AM +0200, Markus Wichmann wrote:
> > > Am Wed, Sep 06, 2023 at 08:46:32PM -0400 schrieb Peter Williams:
> > > > 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?
> > >
> > > I'm guessing the same. Pretty much all architectures have shorter
> > > conditional than unconditional branches. That is why branches to other
> > > files (technically to other sections) should always be unconditional. I
> > > am attaching a simple patch that should help with the situation.
> > >
> > > Ciao,
> > > Markus
> > > From dd227e22a5337d54e1cb0838410bca6672c76c43 Mon Sep 17 00:00:00 2001
> > > From: Markus Wichmann <email@example.com>
> > > Date: Thu, 7 Sep 2023 05:01:23 +0200
> > > Subject: [PATCH] Make branch to external symbol unconditional.
> > >
> > > Conditional branches have a shorter branch length than unconditional
> > > ones, and almost all ABIs require unconditional branches to external
> > > symbols. Otherwise linkers may create broken binaries.
> > > ---
> > > src/signal/aarch64/sigsetjmp.s | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/src/signal/aarch64/sigsetjmp.s b/src/signal/aarch64/sigsetjmp..s
> > > index 75910c43..9a28e395 100644
> > > --- a/src/signal/aarch64/sigsetjmp.s
> > > +++ b/src/signal/aarch64/sigsetjmp.s
> > > @@ -4,7 +4,7 @@
> > > .type __sigsetjmp,%function
> > > sigsetjmp:
> > > __sigsetjmp:
> > > - cbz x1,setjmp
> > > + cbz x1,1f
> > >
> > > str x30,[x0,#176]
> > > str x19,[x0,#176+8+8]
> > > @@ -19,3 +19,5 @@ __sigsetjmp:
> > >
> > > .hidden __sigsetjmp_tail
> > > b __sigsetjmp_tail
> > > +
> > > +1: b setjmp
yeah, this looks good except the commit message can be improved.
conditional branch has +-1M reach, unconditional branch has +-128M
reach and the linker inserts a veneer if unconditional branch goes
further than that (i.e. it can go arbitrarily far).
setjmp is a local symbol to libc (or in case of static linking to
the exe), so using unconditional branch is perfectly fine if we
ensure the linker does not move the symbols far (e.g. putting the
two symbols in the same object file or into the same small section
is enough). this depends on that user code cannot interpose setjmp
(link namespace violation) and setjmp in libc does not use plt.
note that aarch64 libc.so text is < 1M so we can compile it with
-mcmodel=tiny code model and then the compiler would emit cond
branch for libc symbols. but .lo objects built like that are not
suitable for libc.a.
the simple b setjmp is the reasonable fix for now.
> > Are you sure this is the actual problem? I think it's that the aarch64
> > (and several other archs) version of sigsetjmp is wrongly using the
> > public setjmp symbol whose definition is possibly provided by a PLT
> > thunk in the main program, rather than either setjmp@PLT (which would
> > necessarily be the right local call point to use) or the hidden
> > ___setjmp symbol that exists for this purpose (which i386, for
> > example, uses).
> Hmm, no, that seems to be a separate issue. The reported issue is
> indeed a large static link where PLT stuff should not come into play.
> So I think the cbz limited-range is indeed the issue.
next prev parent reply other threads:[~2023-09-07 19:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-07 0:46 Peter Williams
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 [this message]
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).