• Bug#1068350: [musl] Re: Bug#1068350: musl: miscompiles (runtime problem

    From Markus Wichmann@21:1/5 to All on Sat Apr 6 09:50:37 2024
    XPost: linux.debian.bugs.dist

    Hi,

    in static-pie, relocations get processed in _start, before main() is
    called. In musl, this is done by linking with rcrt1.o as start file
    instead of crt1.o. And that file processes all relative relocations. You
    can check with readelf -r what the relocation types are. If they are not relative, they will not be processed.

    What you are seeing seems indicative of missing relocation processing.
    Is it possible you are linking in the wrong start file? gcc -v should
    output the command line it feeds to the linker.

    Ciao,
    Markus

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thorsten Glaser@21:1/5 to All on Sat Apr 6 09:50:38 2024
    XPost: linux.debian.bugs.dist

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Szabolcs Nagy@21:1/5 to All on Sat Apr 6 09:50:48 2024
    XPost: linux.debian.bugs.dist

    * Thorsten Glaser <[email protected]> [2024-04-05 05:04:37 +0000]:
    Markus Wichmann dixit:

    can check with readelf -r what the relocation types are. If they are not >relative, they will not be processed.

    Gotcha! They are all R_390_RELATIVE except for:

    000000045ff0 001100000016 R_390_64 0000000000042c58 u_ops + 70 000000045ff8 001100000016 R_390_64 0000000000042c58 u_ops + 0 000000047020 001100000016 R_390_64 0000000000042c58 u_ops + 80 000000047088 001100000016 R_390_64 0000000000042c58 u_ops + 80 0000000470a8 001100000016 R_390_64 0000000000042c58 u_ops + b8 000000047220 001100000016 R_390_64 0000000000042c58 u_ops + 80 000000046900 002600000016 R_390_64 0000000000015af8 c_command + 0 000000046940 000700000016 R_390_64 0000000000017238 c_exec + 0 000000046ab0 002000000016 R_390_64 0000000000016a80 c_trap + 0 000000047090 002500000016 R_390_64 00000000000430ac initvsn + 0 000000047278 005500000016 R_390_64 0000000000047438 null_string + 2

    That’s our missing strings.


    this is not correct static pie.

    glibc handles symbolic relocs, but there should not be
    any non-local symbol in a static exe. you may want to
    check the symbol table.

    so s390 does not support static pie.
    (arguably the elf is correct, if you expect a full
    dynlinker in a static pie, but even then it's bad
    quality linker output)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thorsten Glaser@21:1/5 to All on Sat Apr 6 09:51:26 2024
    XPost: linux.debian.bugs.dist

    Markus Wichmann dixit:

    can check with readelf -r what the relocation types are. If they are not >relative, they will not be processed.

    Gotcha! They are all R_390_RELATIVE except for:

    000000045ff0 001100000016 R_390_64 0000000000042c58 u_ops + 70 000000045ff8 001100000016 R_390_64 0000000000042c58 u_ops + 0 000000047020 001100000016 R_390_64 0000000000042c58 u_ops + 80 000000047088 001100000016 R_390_64 0000000000042c58 u_ops + 80 0000000470a8 001100000016 R_390_64 0000000000042c58 u_ops + b8 000000047220 001100000016 R_390_64 0000000000042c58 u_ops + 80 000000046900 002600000016 R_390_64 0000000000015af8 c_command + 0 000000046940 000700000016 R_390_64 0000000000017238 c_exec + 0 000000046ab0 002000000016 R_390_64 0000000000016a80 c_trap + 0 000000047090 002500000016 R_390_64 00000000000430ac initvsn + 0 000000047278 005500000016 R_390_64 0000000000047438 null_string + 2

    That’s our missing strings.

    Is it possible you are linking in the wrong start file? gcc -v should
    output the command line it feeds to the linker.

    Should be correct:

    /usr/libexec/gcc/s390x-linux-gnu/13/collect2 -fno-lto -dynamic-linker /lib/ld-musl-s390x.so.1 -nostdlib -static -static -pie --no-dynamic-linker -o mksh /usr/lib/s390x-linux-musl/rcrt1.o /usr/lib/s390x-linux-musl/crti.o /usr/lib/gcc/s390x-linux-gnu/13/
    crtbeginS.o -L/usr/lib/s390x-linux-musl -L /usr/lib/gcc/s390x-linux-gnu/13/. -z relro -z now --as-needed -z text --eh-frame-hdr lalloc.o edit.o eval.o exec.o expr.o funcs.o histrap.o jobs.o lex.o main.o misc.o shf.o syn.o tree.o var.o ulimit.o --start-
    group /usr/lib/gcc/s390x-linux-gnu/13/libgcc.a /usr/lib/gcc/s390x-linux-gnu/13/libgcc_eh.a -lc --end-group /usr/lib/gcc/s390x-linux-gnu/13/crtendS.o /usr/lib/s390x-linux-musl/crtn.o

    HTH & HAND,
    //mirabilos
    --
    „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
    mksh auf jedem System zu installieren.“
    -- XTaran auf der OpenRheinRuhr, ganz begeistert
    (EN: “[…]uhr.gz is a reason to install mksh on every system.”)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rich Felker@21:1/5 to Thorsten Glaser on Sat Apr 6 09:51:44 2024
    XPost: linux.debian.bugs.dist

    On Fri, Apr 05, 2024 at 05:04:37AM +0000, Thorsten Glaser wrote:
    Markus Wichmann dixit:

    can check with readelf -r what the relocation types are. If they are not >relative, they will not be processed.

    Gotcha! They are all R_390_RELATIVE except for:

    000000045ff0 001100000016 R_390_64 0000000000042c58 u_ops + 70 000000045ff8 001100000016 R_390_64 0000000000042c58 u_ops + 0 000000047020 001100000016 R_390_64 0000000000042c58 u_ops + 80 000000047088 001100000016 R_390_64 0000000000042c58 u_ops + 80 0000000470a8 001100000016 R_390_64 0000000000042c58 u_ops + b8 000000047220 001100000016 R_390_64 0000000000042c58 u_ops + 80 000000046900 002600000016 R_390_64 0000000000015af8 c_command + 0 000000046940 000700000016 R_390_64 0000000000017238 c_exec + 0 000000046ab0 002000000016 R_390_64 0000000000016a80 c_trap + 0 000000047090 002500000016 R_390_64 00000000000430ac initvsn + 0 000000047278 005500000016 R_390_64 0000000000047438 null_string + 2

    That’s our missing strings.

    Is there anything weird about how these objects were declared that
    might have caused ld not to resolve them statically like it should? It
    seems odd that these data symbols, but not any other ones, would be
    left as symbolic relocations.

    Rich

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)