From: Markus Wichmann <nullplan@gmx.net>
To: musl@lists.openwall.com
Cc: 1068350@bugs.debian.org, debian-glibc@lists.debian.org, doko@debian.org
Subject: Re: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc
Date: Fri, 5 Apr 2024 08:42:17 +0200 [thread overview]
Message-ID: <Zg-dSTq2FCe7v_2d@voyager> (raw)
In-Reply-To: <Pine.BSM.4.64L.2404050555120.14283@herc.mirbsd.org>
Am Fri, Apr 05, 2024 at 05:58:15AM +0000 schrieb Thorsten Glaser:
> Markus Wichmann dixit:
> >In any case, the emission of non-relative relocations is the issue here,
> >and it is coming from the linker.
>
> They are present in the glibc static-pie binary as well, though.
> And tbh they look to me like “just plug the absolute address of
> the symbol here, please”, which is perfectly fine for things like
> an array of strings when the actual string has already its own symbol.
>
> (Disclaimer: I know… barely anything about Unix relocation types,
> a bit more about those on DOS and even TOS.)
>
Then glibc's static-pie startup code also processes symbolic
relocations. musl's doesn't. It only processes relative relocations. And
changing this would require some massive reworking. We'd somehow have to
put stage 2 of the dynamic linker into rcrt1.o.
A symbolic lookup doesn't really make sense for a static executable
outside of FDPIC. The only difference in address space possible is a
relative offset. In order to do a symbolic relocation, you also need the
symbol lookup stuff, which - granted - for a static PIE is probably
very simple because there can be only one symbol table, but still.
I thought the whole point of static-PIE support was to only leave
relative relocations around.
Ciao,
Markus
next prev parent reply other threads:[~2024-04-05 6:42 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <171218457890.157989.17235252523998125898.reportbug@zelenka.debian.org>
2024-04-03 23:57 ` [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on s390x with static-pie Thorsten Glaser
2024-04-04 10:44 ` Szabolcs Nagy
2024-04-04 10:54 ` Szabolcs Nagy
2024-04-04 19:50 ` [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and " Thorsten Glaser
2024-04-04 20:26 ` Rich Felker
2024-04-04 20:40 ` Thorsten Glaser
2024-04-04 21:18 ` [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc Thorsten Glaser
2024-04-05 0:26 ` Thorsten Glaser
2024-04-05 4:11 ` Markus Wichmann
2024-04-05 5:04 ` Thorsten Glaser
2024-04-05 5:31 ` Markus Wichmann
2024-04-05 5:58 ` Thorsten Glaser
2024-04-05 6:42 ` Markus Wichmann [this message]
2024-04-05 6:48 ` Szabolcs Nagy
2024-04-06 3:00 ` Rich Felker
2024-04-06 15:18 ` Thorsten Glaser
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=Zg-dSTq2FCe7v_2d@voyager \
--to=nullplan@gmx.net \
--cc=1068350@bugs.debian.org \
--cc=debian-glibc@lists.debian.org \
--cc=doko@debian.org \
--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).