Re: Toybox make root no longer works as expected

On 14 Jul 14:32, Rob Landley wrote:
> 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.

The offending code could be reduced to this testcase via cvise:
(see also godbolt [0]).

    struct __large_struct { unsigned long buf[100]; };
    long long g;
    void f(void)
    {
        __asm__ __volatile__("mov.l     %R0,r0" : : "m"(*(struct __large_struct *)&g));
    }


[0] https://godbolt.org/z/MWT9c6113