Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 5 Apr 2024 05:58:15 +0000 (UTC)
From: Thorsten Glaser <tg@...bsd.de>
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

Markus Wichmann dixit:

>I may not really know what I am talking about, so take this with a grain
>of salt, but isn't this missing a -Bsymbolic somewhere? Ironically, that
>switch causes ld to not emit symbolic relocations. I seem to remember
>reading long ago in Rich's initial -static-pie proposal that that was
>one of the switches added to the linker command line.

When searching for which architectures support static PIE in the first
place (sadly, there doesn’t seem a consistent list), I found one saying
it’s no longer necessart after some point, so I didn’t check it.

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

bye,
//mirabilos
-- 
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival

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.