[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 5 Apr 2024 08:42:17 +0200
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Cc: 1068350@...s.debian.org, debian-glibc@...ts.debian.org, doko@...ian.org
Subject: Re: 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
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
