Re: Toybox make root no longer works as expected

On 7/14/26 02:47, Florian Fuchs wrote:
> I also crafted a bit with gcc-17, and my first issue was a duplicate
> symbols (LPCS0) compiling libgcc like in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89012 I could only work
> around with explicitly using O1 instead of O2 in INTERNAL_CFLAGS of gcc.

My notes say GCC commit 551935d11817 introduced that failure. Dunno why, 
it's big. The two largest chunks of it are:

  gcc/gimple-harden-control-flow.cc       | 1488 ++++++++++
  libgcc/hardcfr.c                        |  300 ++

> And errors with libbacktrace, I worked around by --enable-languages=c

I hadn't even made it to that yet...

> I got gcc to not ICE, but it then fails with invalid assembler thats why
> I became suspicious about the asm in question.

Yes, I'd found that failing kernel file, ran it through gcc -E to get a 
standalone one, and then tried to compile it with the sh4eb compiler 
(rather than sh2eb) and got the same ICE. Jeff immediately suspected it 
was sh2 #ifdefs in arch/sh/include but unfortunately my usual attempts 
to strip down the test case failed because if you remove much the ICE 
failed to happen (since it's a jump-too-far thing). It's GOTTA be big.

The commit that introduced the behavior is, of course, adding tens of 
kilobytes of new code to the linux kernel in a syscall you can't 
configure out, because linux-kernel. (Play the katamari damacy theme.)

https://github.com/torvalds/linux/commit/76b6f5dfb3fd

> turns out, delcaring the
> adresses as offsetable, seems to "fix" the ICE and compile and work for
> fdpic, means it is maybe not necessarily only a GCC issue.

The gcc issue is terrible error reporting. The assembler swallows some 
assembly inline statements that don't work in context and barfs because 
"that jump can't make it to that label", then can't properly report the 
error back up the stack as anything other than "bad thing happened deep 
in the bowels of the gnu/hairball that RMS explicitly tied together 
because he didn't want people to use gcc's frontend to develop a new 
backend like llvm literally did anyway, ia ia gnu/Stallman ftaghn".

Seriously, the ICE even happened running "gcc -S" so I couldn't look at 
the assembly output it was telling me about. It complained about error 
on assembly line blah but DIDN'T FLUSH THAT ASSEMBLY TO THE OUTPUT 
BEFORE DYING. Grrr. Maybe a missing fflush(0) in the error exit path?

> diff --git a/arch/sh/include/asm/uaccess_32.h b/arch/sh/include/asm/uaccess_32.h
> index 5d7ddc092afd..cef40414bfb1 100644
> --- a/arch/sh/include/asm/uaccess_32.h
> +++ b/arch/sh/include/asm/uaccess_32.h
> @@ -92,7 +92,7 @@ __asm__ __volatile__( \
>   	".long	1b + 2, 3b\n\t" \
>   	".previous" \
>   	:"=&r" (err), "=&r" (x) \
> -	:"m" (__m(addr)), "i" (-EFAULT), "0" (err)); })
> +	:"o" (__m(addr)), "i" (-EFAULT), "0" (err)); })

These are probably actually the correct fix, not a workaround, and maybe 
should get pushed to Linus. (With a commit message referencing how linux 
commit 76b6f5dfb3fd added so much unconditional new code to a single 
translation unit (which could not be disabled by a config symbol) that 
the jump couldn't span it and had to be promoted to a larger type, and 
gcc gave a terrible error message that slowed us down fixing it.)

Rob

P.S. Jeff apologized over Signal: he's caught some sort of flu/covid and 
is offline for a few days.