[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 <tg@mirbsd.de>]

Dixi quod…

>Hmm, actually… I could… test whether that one fixes static-pie
>on zelenka. Or at least the same approach. I’ll get back with
>report from that.

Having looked at the spec file, the only extra things the stock
specs do that the overriding specs don’t is:

*link:
[…] %{!static|static-pie:--eh-frame-hdr} […] %{static-pie:-static -pie --no-dynamic-linker -z text} […]

instead of:

[…] %{static-pie:-static -pie --no-dynamic-linker} […]

The -Wl,-z,text makes TEXTRELs an error. Granted.
The -Wl,--eh-frame-hdr is added for anything that’s not a normal
static executable, however adding that to a musl build doesn’t
fix the problem either.

A bit of gdb-ing shows the problem, though: the source code has…

#define Ttypeset "typeset"
#define Tdr "-r"
//… (a variant of this is used for string sharing on ancient Unix)

static const char *initcoms[] = {
	Ttypeset, Tdr, initvsn, NULL,
	Ttypeset, Tdx, "HOME", TPATH, TSHELL, NULL,
  […]
};

It then iterates over these commands with:

for (wp = initcoms; *wp != NULL; wp++) {
	c_builtin(wp);
	while (*wp != NULL)
		wp++;
}

This is where the extra output happens:

(gdb) print initcoms
$3 = {0x3fff7fc14a4 "typeset", 0x0, 0x0, 0x0, 0x3fff7fc14a4 "typeset", 0x0, 0x3fff7fc0478 "HOME", 
[…]

Notice the nullptrs there where string pointers are expected.
It shows the same output when just loading the executable, i.e. this
isn’t a runtime issue.

Linking the exact same .o files with the exact same command minus
-static-pie gives:

(gdb) print initcoms
$1 = {0x103cb34 "typeset", 0x103e368 <u_ops+128> "-r", 
  0x103e73c <initvsn> "KSH_VERSION=@(#)MIRBSD KSH R59 2024/02/01 +Debian", 0x0, 0x103cb34 "typeset", 

But this does seem to be a toolchain bug: adding -static-pie to the
glibc dynamic-pie link command and…

(gdb) print initcoms
$1 = {0xda494 "typeset", 0x0, 0x0, 0x0, 0xda494 "typeset", 0x0, 0xd942c "HOME", 0xda7d8 "PATH",

Now I (or someone) is going to have to reduce that to a testcase, so
we can detect static-pie viability before it’s committed to being used…

bye,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.		-- Andreas Bogk über boehm-gc in d.a.s.r