Toybox make root no longer works as expected

Toybox make root no longer works as expected

[John Paul Adrian Glaubitz]

Hi Rob,

I'm trying to build a new root image after updating Toybox but that no longer works:

glaubitz@node54:/data/home/glaubitz/toybox> make root CROSS=sh2eb-linux-muslfdpic- LINUX=/data/home/glaubitz/sh-linux
mkroot/mkroot.sh  -- LINUX=/data/home/glaubitz/sh-linux CROSS=sh2eb-linux-muslfdpic-
No ccc symlink to compiler directory.
make: *** [Makefile:108: root] Error 1
glaubitz@node54:/data/home/glaubitz/toybox>

It asks me to create a "ccc" symlink but I have no clue where that link is supposed
to point to. The FAQ says the link is supposed to »pointing at a directory full of
cross compilers« but I don't have that and that's not my personal setup. I have the
cross compilers installed in my home directory and their bin directories added to
the PATH variable which has always worked in the past without any problems.

Can you explain how that "ccc" symlink works?

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Toybox make root no longer works as expected

[John Paul Adrian Glaubitz]

Hi,

On Wed, 2026-04-29 at 09:46 +0200, John Paul Adrian Glaubitz wrote:
> I'm trying to build a new root image after updating Toybox but that no longer works:
> 
> glaubitz@node54:/data/home/glaubitz/toybox> make root CROSS=sh2eb-linux-muslfdpic- LINUX=/data/home/glaubitz/sh-linux
> mkroot/mkroot.sh  -- LINUX=/data/home/glaubitz/sh-linux CROSS=sh2eb-linux-muslfdpic-
> No ccc symlink to compiler directory.
> make: *** [Makefile:108: root] Error 1
> glaubitz@node54:/data/home/glaubitz/toybox>
> 
> It asks me to create a "ccc" symlink but I have no clue where that link is supposed
> to point to. The FAQ says the link is supposed to »pointing at a directory full of
> cross compilers« but I don't have that and that's not my personal setup. I have the
> cross compilers installed in my home directory and their bin directories added to
> the PATH variable which has always worked in the past without any problems.
> 
> Can you explain how that "ccc" symlink works?

OK, for some reason it works now. Unfortunately, the toolchain doesn't like the current kernel:

  CC      net/ipv4/inetpeer.o
during RTL pass: final
In file included from kernel/nstree.c:8:
kernel/nstree.c: In function '__se_sys_listns':
./include/linux/syscalls.h:261:9: internal compiler error: in change_address_1, at emit-rtl.c:2275
  261 |         }                                                               \
      |         ^
./include/linux/syscalls.h:236:9: note: in expansion of macro '__SYSCALL_DEFINEx'
  236 |         __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
      |         ^~~~~~~~~~~~~~~~~
./include/linux/syscalls.h:228:36: note: in expansion of macro 'SYSCALL_DEFINEx'
  228 | #define SYSCALL_DEFINE4(name, ...) SYSCALL_DEFINEx(4, _##name, __VA_ARGS__)
      |                                    ^~~~~~~~~~~~~~~
kernel/nstree.c:763:1: note: in expansion of macro 'SYSCALL_DEFINE4'
  763 | SYSCALL_DEFINE4(listns, const struct ns_id_req __user *, req,
      | ^~~~~~~~~~~~~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
{standard input}: Assembler messages:
{standard input}: Warning: end of file not at end of a line; newline inserted
{standard input}:1592: Error: missing operand
{standard input}:1592: Error: invalid operands for opcode
{standard input}:976: Error: displacement to undefined symbol .L339 overflows 12-bit field
{standard input}:1014: Error: displacement to undefined symbol .L459 overflows 12-bit field
{standard input}:1028: Error: displacement to undefined symbol .L340 overflows 12-bit field
{standard input}:1040: Error: displacement to undefined symbol .L461 overflows 12-bit field
{standard input}:1060: Error: displacement to undefined symbol .L462 overflows 12-bit field
{standard input}:1082: Error: displacement to undefined symbol .L463 overflows 12-bit field
{standard input}:1100: Error: displacement to undefined symbol .L252 overflows 12-bit field
{standard input}:1201: Error: displacement to undefined symbol .L286 overflows 12-bit field
{standard input}:1211: Error: displacement to undefined symbol .L468 overflows 12-bit field
{standard input}:1221: Error: displacement to undefined symbol .L298 overflows 12-bit field
{standard input}:1234: Error: displacement to undefined symbol .L469 overflows 12-bit field
{standard input}:1256: Error: displacement to undefined symbol .L349 overflows 12-bit field
{standard input}:1341: Error: displacement to undefined symbol .L314 overflows 12-bit field
{standard input}:1488: Error: displacement to undefined symbol .L454 overflows 8-bit field 
{standard input}:1498: Error: displacement to undefined symbol .L471 overflows 8-bit field 
make[3]: *** [scripts/Makefile.build:289: kernel/nstree.o] Error 1
make[3]: *** Waiting for unfinished jobs....

Adrian

Re: Toybox make root no longer works as expected

[D. Jeff Dionne]

Hey Adrian,

Can you do a --version on that toolchain gcc for me please.  Overflow and internal compiler error suggest maybe -mj2 is not in the command line, for instance.

In the meantime, here is the (IIRC current) build script we use to generate toolchains for J-Core J2 J1 Linux and bare metal.  It’s a but convoluted, patches on patches… no one has the time to clean this up as we’d like.

https://codeberg.org/J-Core/librelane-vhdl-build/src/branch/master/01-toolchains.sh

Cheers,
J.

> On Apr 30, 2026, at 15:57, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
> 
> Hi,
> 
> On Wed, 2026-04-29 at 09:46 +0200, John Paul Adrian Glaubitz wrote:
>> I'm trying to build a new root image after updating Toybox but that no longer works:
>> 
>> glaubitz@node54:/data/home/glaubitz/toybox> make root CROSS=sh2eb-linux-muslfdpic- LINUX=/data/home/glaubitz/sh-linux
>> mkroot/mkroot.sh  -- LINUX=/data/home/glaubitz/sh-linux CROSS=sh2eb-linux-muslfdpic-
>> No ccc symlink to compiler directory.
>> make: *** [Makefile:108: root] Error 1
>> glaubitz@node54:/data/home/glaubitz/toybox>
>> 
>> It asks me to create a "ccc" symlink but I have no clue where that link is supposed
>> to point to. The FAQ says the link is supposed to »pointing at a directory full of
>> cross compilers« but I don't have that and that's not my personal setup. I have the
>> cross compilers installed in my home directory and their bin directories added to
>> the PATH variable which has always worked in the past without any problems.
>> 
>> Can you explain how that "ccc" symlink works?
> 
> OK, for some reason it works now. Unfortunately, the toolchain doesn't like the current kernel:
> 
>  CC      net/ipv4/inetpeer.o
> during RTL pass: final
> In file included from kernel/nstree.c:8:
> kernel/nstree.c: In function '__se_sys_listns':
> ./include/linux/syscalls.h:261:9: internal compiler error: in change_address_1, at emit-rtl.c:2275
>  261 |         }                                                               \
>      |         ^
> ./include/linux/syscalls.h:236:9: note: in expansion of macro '__SYSCALL_DEFINEx'
>  236 |         __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
>      |         ^~~~~~~~~~~~~~~~~
> ./include/linux/syscalls.h:228:36: note: in expansion of macro 'SYSCALL_DEFINEx'
>  228 | #define SYSCALL_DEFINE4(name, ...) SYSCALL_DEFINEx(4, _##name, __VA_ARGS__)
>      |                                    ^~~~~~~~~~~~~~~
> kernel/nstree.c:763:1: note: in expansion of macro 'SYSCALL_DEFINE4'
>  763 | SYSCALL_DEFINE4(listns, const struct ns_id_req __user *, req,
>      | ^~~~~~~~~~~~~~~
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <https://gcc.gnu.org/bugs/> for instructions.
> {standard input}: Assembler messages:
> {standard input}: Warning: end of file not at end of a line; newline inserted
> {standard input}:1592: Error: missing operand
> {standard input}:1592: Error: invalid operands for opcode
> {standard input}:976: Error: displacement to undefined symbol .L339 overflows 12-bit field
> {standard input}:1014: Error: displacement to undefined symbol .L459 overflows 12-bit field
> {standard input}:1028: Error: displacement to undefined symbol .L340 overflows 12-bit field
> {standard input}:1040: Error: displacement to undefined symbol .L461 overflows 12-bit field
> {standard input}:1060: Error: displacement to undefined symbol .L462 overflows 12-bit field
> {standard input}:1082: Error: displacement to undefined symbol .L463 overflows 12-bit field
> {standard input}:1100: Error: displacement to undefined symbol .L252 overflows 12-bit field
> {standard input}:1201: Error: displacement to undefined symbol .L286 overflows 12-bit field
> {standard input}:1211: Error: displacement to undefined symbol .L468 overflows 12-bit field
> {standard input}:1221: Error: displacement to undefined symbol .L298 overflows 12-bit field
> {standard input}:1234: Error: displacement to undefined symbol .L469 overflows 12-bit field
> {standard input}:1256: Error: displacement to undefined symbol .L349 overflows 12-bit field
> {standard input}:1341: Error: displacement to undefined symbol .L314 overflows 12-bit field
> {standard input}:1488: Error: displacement to undefined symbol .L454 overflows 8-bit field 
> {standard input}:1498: Error: displacement to undefined symbol .L471 overflows 8-bit field 
> make[3]: *** [scripts/Makefile.build:289: kernel/nstree.o] Error 1
> make[3]: *** Waiting for unfinished jobs....
> 
> Adrian
> 

Re: Toybox make root no longer works as expected

[John Paul Adrian Glaubitz]

Hi Jeff,

On Thu, 2026-04-30 at 16:13 +0900, D. Jeff Dionne wrote:
> Can you do a --version on that toolchain gcc for me please.  Overflow and internal
> compiler error suggest maybe -mj2 is not in the command line, for instance.

I'm using Rob's toolchain from 2024:

glaubitz@node54:/data/home/glaubitz> sh2eb-linux-muslfdpic-cc --version
sh2eb-linux-muslfdpic-cc (GCC) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

glaubitz@node54:/data/home/glaubitz>

> In the meantime, here is the (IIRC current) build script we use to generate toolchains
> for J-Core J2 J1 Linux and bare metal.  It’s a but convoluted, patches on patches…
> no one has the time to clean this up as we’d like.
> 
> https://codeberg.org/J-Core/librelane-vhdl-build/src/branch/master/01-toolchains.sh

I can give it a try. Would be good if Rob could publish a recent version of the toolchain.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Toybox make root no longer works as expected

[Rob Landley]

On 4/29/26 02:46, John Paul Adrian Glaubitz wrote:
> Hi Rob,
> 
> I'm trying to build a new root image after updating Toybox but that no longer works:
> 
> glaubitz@node54:/data/home/glaubitz/toybox> make root CROSS=sh2eb-linux-muslfdpic- LINUX=/data/home/glaubitz/sh-linux
> mkroot/mkroot.sh  -- LINUX=/data/home/glaubitz/sh-linux CROSS=sh2eb-linux-muslfdpic-
> No ccc symlink to compiler directory.

You're using CROSS= with the CROSS_COMPILE= syntax. They mean different 
things.

CROSS= is the syntax that just specifies the target architecture and 
picks a cross compiler from a common directory (pointed to by ccc). The 
special names CROSS=all and CROSS=allnonstop build all the targets (the 
first stopping upon failure, the second continuing past failures. See 
root/build/log for log files afterwards, the extension .y is builds that 
succeeded, .n is builds that didn't succeed, and .txt is every command 
line run out of the $PATH when building.)

CROSS_COMPILE= specifies a compiler prefix to use out of the $PATH, or 
you can CROSS_COMPILE=/path/to/prefix- to supply path and prefix in one. 
In which case the plumbing will use the start of the prefix up to the 
first dash as the target architecture name for finding the kernel config 
and so on out of the big if/else staircase. (I should provide a way to 
independently override that, but it hasn't come up much.)

If you don't specify either it builds using the host compiler, which is 
usually linking against glibc and thus absolutely incompetent at 
producing static binaries.

The supported targets and corresponding config data derived from them 
(kernel config and KARCH, qemu command line invocation including 
specifying the right serial output type, which file is actually the 
runnable kernel produced by the build, etc) are under 
https://codeberg.org/landley/toybox/src/branch/master/mkroot/mkroot.sh#L183 
which sets default values first and then overrides them for targets that 
don't use the most common option in a big if/else staircase.

For example, everything mkroot knows about the m68k target is:

>   elif [ "$CROSS" == m68k ]; then
>     QEMU_M=q800 KARCH=m68k
>     KCONF="$(be2csv MMU M68040 M68KFPU_EMU MAC BLK_DEV_SD MACINTOSH_DRIVERS \
>       NET_VENDOR_NATSEMI MACSONIC SCSI{,_LOWLEVEL,_MAC_ESP} \
>       SERIAL_PMACZILOG{,_TTYS,_CONSOLE})"

Which says qemu-system-m68k needs "-m q800" but otherwise uses the 
default qemu-system-$ARCH invocation (line 333, or see run-qemu.sh in 
any existing image), and that kernel needs ARCH=m68k.

Then KCONFIG= specifies kernel .config symbols in a very terse format, 
which is expanded three times:

1) be2csv = brace expansion to comma separated values, so bash's 
SCSI{,_LOWLEVEL,_MAC_ESP} becomes SCSI SCSI_LOWLEVEL SCSI_MAC_ESP and 
then all the spaces are turned into commas

2) csv2cfg produces miniconfig output, the above three becoming:

CONFIG_SCSI=y
CONFIG_SCSI_LOWLEVEL=y
CONFIG_SCSI_MAC_ESP=y

(Note that if one of the CSV is of the form BLAH=something then the 
=something will be used instead of adding =y, and yes it understands 
that commas inside "double quotes" are part of that value, not symbol 
separators. That's why the regex in csv2cfg is so horrible. If you need 
blah="thing with spaces" you can KCONF+=,symbol without running it 
through be2csv, as at least one architecture used to do? Or did I switch 
that to KCONFIG="$(be2csv blah),MORE=\"thing with spaces\"" for 
that/those target(s)? I forget...)

3) it's fed into the kernel's miniconfig plumbing which I documented 
twenty one years ago (yes in 2005, https://lwn.net/Articles/161086/). 
The plumbing glues on the GENERIC_KCONF list of default symbols (so I 
don't have to tell EVERY target to support ELF or ext2) and then calls

make allnoconfig KCONFIG_ALLCONFIG=mini.config

Those are the three files memorialized in root/sh4/docs and similar, by 
the way. The microconfig (csv after brace expansion), the miniconfig, 
and the full (sadly very version-specific) .config.

> make: *** [Makefile:108: root] Error 1
> glaubitz@node54:/data/home/glaubitz/toybox>
> 
> It asks me to create a "ccc" symlink but I have no clue where that link is supposed
> to point to.

It's at the end of https://landley.net/toybox/faq.html#cross although 
that links to another section which is a bit verbose...

> The FAQ says the link is supposed to »pointing at a directory full of
> cross compilers« but I don't have that and that's not my personal setup.

The ones I built are at https://landley.net/bin/toolchains/latest

You can extract the -cross ones from there into a directory for ccc to 
point at. (The -native.sqf ones are squashfs filesystems you can add to 
qemu with -hda or network block devices or similar.)

> I have the
> cross compilers installed in my home directory and their bin directories added to
> the PATH variable which has always worked in the past without any problems.

Try CROSS_COMPILE instead of CROSS, they mean different things.

> Can you explain how that "ccc" symlink works?

It contains directories called $ARCH-*cross and expects to find a 
compiler called $ARCH-*cross/bin/$CROSS*-cc in each. (It doesn't HAVE to 
be a symlink, it can be a directory, but installing piles of stuff under 
your get repo is not ideal.)

If the ccc/ directory exists and try to CROSS=help or something (any 
target it can't find), it lists the available targets.

> Thanks,
> Adrian

Rob

Re: Toybox make root no longer works as expected

[John Paul Adrian Glaubitz]

Hi Rob,

On Thu, 2026-04-30 at 15:10 -0500, Rob Landley wrote:
> On 4/29/26 02:46, John Paul Adrian Glaubitz wrote:
> > Hi Rob,
> > 
> > I'm trying to build a new root image after updating Toybox but that no longer works:
> > 
> > glaubitz@node54:/data/home/glaubitz/toybox> make root CROSS=sh2eb-linux-muslfdpic- LINUX=/data/home/glaubitz/sh-linux
> > mkroot/mkroot.sh  -- LINUX=/data/home/glaubitz/sh-linux CROSS=sh2eb-linux-muslfdpic-
> > No ccc symlink to compiler directory.
> 
> You're using CROSS= with the CROSS_COMPILE= syntax. They mean different 
> things.
> (...)

Thanks for the elaborate explanation! I had found the mistake in the mean time. However,
I still can't build the kernel since GCC fails with an internal compiler error as mentioned
in my previous reply.

Could you maybe build an updated toolchain for sh2eb which is based on a more recent GCC
version?

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Toybox make root no longer works as expected

[D. Jeff Dionne]

On May 1, 2026, at 07:46, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

> Could you maybe build an updated toolchain for sh2eb which is based on a more recent GCC version?

The main problem here, I think if it’s a version issue, is there is breakage in the GCC optimiser when used against the SH backend.  But it could also be the J-Core instruction set variant of SH2.

GCC 9.4 is probably what you need, we don’t actually use GCC 11… Rob uses a different work flow methodology, with the goal of self contained builds.  Most of us benefit from 'golden compilers' on the path, and for J-Core that been GCC 9.4 series because of similar problems.  This choice came about after some testing, so it’s what Rich Felker’s musl cross make still does.  The results of that build script are used in every day work.

Yeah.  There is a need to properly fund work on the embedded compilers, and I don’t mean LLVM, which again has different goals.  I see a lot of folks and project suffering from the limitations that come from using ‘Linux’ compilers as if they were a generic cross compiler.  Retro BSD comes to mind.

Let me pull a kernel and see if I can reproduce your build failure.  I’ll try and do that over the weekend, or at least over Golden Week.

Cheers,
J.

> 
> Thanks,
> Adrian

Re: Toybox make root no longer works as expected

[John Paul Adrian Glaubitz]

Hi Jeff,

On Fri, 2026-05-01 at 12:44 +0900, D. Jeff Dionne wrote:
> On May 1, 2026, at 07:46, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
> 
> > Could you maybe build an updated toolchain for sh2eb which is based on a more recent GCC version?
> 
> The main problem here, I think if it’s a version issue, is there is breakage in the GCC optimiser
> when used against the SH backend.  But it could also be the J-Core instruction set variant of SH2.
> 
> GCC 9.4 is probably what you need, we don’t actually use GCC 11… Rob uses a different work flow
> methodology, with the goal of self contained builds.  Most of us benefit from 'golden compilers'
> on the path, and for J-Core that been GCC 9.4 series because of similar problems.  This choice
> came about after some testing, so it’s what Rich Felker’s musl cross make still does.  The results
> of that build script are used in every day work.

GCC 9.4.0 has the same problem, unfortunately:

glaubitz@node54:/data/home/glaubitz/toybox.good> sh2eb-linux-muslfdpic-cc --version
sh2eb-linux-muslfdpic-cc (GCC) 9.4.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

glaubitz@node54:/data/home/glaubitz/toybox.good> 


  CC      io_uring/bpf_filter.o
during RTL pass: final
In file included from kernel/nstree.c:8:
kernel/nstree.c: In function '__se_sys_listns':
./include/linux/syscalls.h:261:2: internal compiler error: in change_address_1, at emit-rtl.c:2286
  261 |  }        \
      |  ^
./include/linux/syscalls.h:236:2: note: in expansion of macro '__SYSCALL_DEFINEx'
  236 |  __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
      |  ^~~~~~~~~~~~~~~~~
./include/linux/syscalls.h:228:36: note: in expansion of macro 'SYSCALL_DEFINEx'
  228 | #define SYSCALL_DEFINE4(name, ...) SYSCALL_DEFINEx(4, _##name, __VA_ARGS__)
      |                                    ^~~~~~~~~~~~~~~
kernel/nstree.c:763:1: note: in expansion of macro 'SYSCALL_DEFINE4'
  763 | SYSCALL_DEFINE4(listns, const struct ns_id_req __user *, req,
      | ^~~~~~~~~~~~~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
{standard input}: Assembler messages:
{standard input}: Warning: end of file not at end of a line; newline inserted
{standard input}:1547: Error: missing operand
{standard input}:1547: Error: invalid operands for opcode
{standard input}:1004: Error: displacement to undefined symbol .L344 overflows 12-bit field
{standard input}:1042: Error: displacement to undefined symbol .L456 overflows 12-bit field
{standard input}:1049: Error: displacement to undefined symbol .L588 overflows 12-bit field
{standard input}:1056: Error: displacement to undefined symbol .L345 overflows 12-bit field
{standard input}:1068: Error: displacement to undefined symbol .L458 overflows 12-bit field
{standard input}:1085: Error: displacement to undefined symbol .L459 overflows 12-bit field
{standard input}:1095: Error: displacement to undefined symbol .L252 overflows 12-bit field
{standard input}:1107: Error: displacement to undefined symbol .L346 overflows 12-bit field
{standard input}:1116: Error: displacement to undefined symbol .L254 overflows 12-bit field
{standard input}:1119: Error: displacement to undefined symbol .L256 overflows 12-bit field
{standard input}:1159: Error: displacement to undefined symbol .L339 overflows 12-bit field
{standard input}:1322: Error: displacement to undefined symbol .L451 overflows 12-bit field
{standard input}:1335: Error: displacement to undefined symbol .L355 overflows 12-bit field
{standard input}:1379: Error: displacement to undefined symbol .L588 overflows 12-bit field
{standard input}:1436: Error: displacement to undefined symbol .L295 overflows 8-bit field 
{standard input}:1439: Error: displacement to undefined symbol .L466 overflows 8-bit field 
{standard input}:1455: Error: displacement to undefined symbol .L292 overflows 12-bit field
{standard input}:1465: Error: displacement to undefined symbol .L468 overflows 12-bit field
{standard input}:1475: Error: displacement to undefined symbol .L304 overflows 12-bit field
{standard input}:1488: Error: displacement to undefined symbol .L353 overflows 12-bit field
{standard input}:1497: Error: displacement to undefined symbol .L306 overflows 12-bit field
{standard input}:1510: Error: displacement to undefined symbol .L354 overflows 12-bit field
{standard input}:1414: Error: pcrel too far
{standard input}:1417: Error: pcrel too far
{standard input}:1500: Error: pcrel too far
make[3]: *** [scripts/Makefile.build:289: kernel/nstree.o] Error 1
make[3]: *** Waiting for unfinished jobs....
  CC      kernel/utsname_sysctl.o

Might be an idea to try an LRA-enabled GCC [1].

Adrian

> [1] https://github.com/olegendo/gcc/tree/devel/sh-lra

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Toybox make root no longer works as expected

[Rob Landley]

On 4/30/26 01:57, John Paul Adrian Glaubitz wrote:
> Hi,
> 
> On Wed, 2026-04-29 at 09:46 +0200, John Paul Adrian Glaubitz wrote:
>> I'm trying to build a new root image after updating Toybox but that no longer works:
>>
>> glaubitz@node54:/data/home/glaubitz/toybox> make root CROSS=sh2eb-linux-muslfdpic- LINUX=/data/home/glaubitz/sh-linux
>> mkroot/mkroot.sh  -- LINUX=/data/home/glaubitz/sh-linux CROSS=sh2eb-linux-muslfdpic-
>> No ccc symlink to compiler directory.
>> make: *** [Makefile:108: root] Error 1
>> glaubitz@node54:/data/home/glaubitz/toybox>
>>
>> It asks me to create a "ccc" symlink but I have no clue where that link is supposed
>> to point to. The FAQ says the link is supposed to »pointing at a directory full of
>> cross compilers« but I don't have that and that's not my personal setup. I have the
>> cross compilers installed in my home directory and their bin directories added to
>> the PATH variable which has always worked in the past without any problems.
>>
>> Can you explain how that "ccc" symlink works?
> 
> OK, for some reason it works now. Unfortunately, the toolchain doesn't like the current kernel:

The last one I tested was 6.17. I keep meaning to poke at newer but if 
the OS age discrimination stuff takes effect without anybody but me 
fighting back, I'm out.

(Government permission required to reinstall your own devices, with 
$7500 fines per download if you dare post a noncompliant image, modeled 
on texas abortion bounties? That is not a "fun hobby" to participate in. 
China can supply us operating systems along with the hardware. But that 
is Gavin "spyware" Newsom's current law going into effect Jan 1, which I 
100% expect to get wired up to Palantir's Persona/Clear and UEFI Secure 
Boot as soon as this round gets appealed to and re-approved by the 
Roberts supreme court. Because people anonymously organizing against ICE 
via signal made the billionaires uncomfortable.)

>    CC      net/ipv4/inetpeer.o
> during RTL pass: final
> In file included from kernel/nstree.c:8:
> kernel/nstree.c: In function '__se_sys_listns':
> ./include/linux/syscalls.h:261:9: internal compiler error: in change_address_1, at emit-rtl.c:2275
>    261 |         }                                                               \
>        |         ^
> ./include/linux/syscalls.h:236:9: note: in expansion of macro '__SYSCALL_DEFINEx'
>    236 |         __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
>        |         ^~~~~~~~~~~~~~~~~
> ./include/linux/syscalls.h:228:36: note: in expansion of macro 'SYSCALL_DEFINEx'
>    228 | #define SYSCALL_DEFINE4(name, ...) SYSCALL_DEFINEx(4, _##name, __VA_ARGS__)
>        |                                    ^~~~~~~~~~~~~~~
> kernel/nstree.c:763:1: note: in expansion of macro 'SYSCALL_DEFINE4'
>    763 | SYSCALL_DEFINE4(listns, const struct ns_id_req __user *, req,
>        | ^~~~~~~~~~~~~~~
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <https://gcc.gnu.org/bugs/> for instructions.
> {standard input}: Assembler messages:
> {standard input}: Warning: end of file not at end of a line; newline inserted
> {standard input}:1592: Error: missing operand
> {standard input}:1592: Error: invalid operands for opcode
> {standard input}:976: Error: displacement to undefined symbol .L339 overflows 12-bit field
> {standard input}:1014: Error: displacement to undefined symbol .L459 overflows 12-bit field
> {standard input}:1028: Error: displacement to undefined symbol .L340 overflows 12-bit field
> {standard input}:1040: Error: displacement to undefined symbol .L461 overflows 12-bit field
> {standard input}:1060: Error: displacement to undefined symbol .L462 overflows 12-bit field
> {standard input}:1082: Error: displacement to undefined symbol .L463 overflows 12-bit field
> {standard input}:1100: Error: displacement to undefined symbol .L252 overflows 12-bit field
> {standard input}:1201: Error: displacement to undefined symbol .L286 overflows 12-bit field
> {standard input}:1211: Error: displacement to undefined symbol .L468 overflows 12-bit field
> {standard input}:1221: Error: displacement to undefined symbol .L298 overflows 12-bit field
> {standard input}:1234: Error: displacement to undefined symbol .L469 overflows 12-bit field
> {standard input}:1256: Error: displacement to undefined symbol .L349 overflows 12-bit field
> {standard input}:1341: Error: displacement to undefined symbol .L314 overflows 12-bit field
> {standard input}:1488: Error: displacement to undefined symbol .L454 overflows 8-bit field
> {standard input}:1498: Error: displacement to undefined symbol .L471 overflows 8-bit field
> make[3]: *** [scripts/Makefile.build:289: kernel/nstree.o] Error 1
> make[3]: *** Waiting for unfinished jobs....

You can always bisect that sort of thing to a specific commit, which 
then doesn't always need a root cause or proper fix to avoid 
_triggering_ the problem that didn't used to trigger.

You don't even need mkroot to do it, on most targets the initramfs is 
external (qemu -initrd option) rather than static, and even when it's 
static you can build it ahead of time and feed it in from a fixed 
location. (And almost never need to because about the only thing that 
would change at compile time is offsets, and overflows are RELATIVE 
offsets with a translation unit not long jumps between units. Module 
that --whole-tree stuff which I didn't think the kernel was using 
because it would make module support a huge pain?)

I _think_ I built 7.0 when it came out and it at least compiled for sh4? 
So probably something since then. (Sigh, I should cut a toybox release 
before 
https://osselcna2026.sched.com/event/2JQxw/building-the-simplest-possible-linux-system-rob-landley-hobbyist?iframe=no 
just so I'm providing the simplest explanation, which means I should 
ship 7.0 binaries. Seems kinda pointless if I have to delete it all 
before new year's, but I committed to giving the talk...)

> Adrian

Rob

Re: Toybox make root no longer works as expected

[Rob Landley]

On 4/30/26 02:17, John Paul Adrian Glaubitz wrote:
> I can give it a try. Would be good if Rob could publish a recent version of the toolchain.

It's just 
https://codeberg.org/landley/toybox/src/branch/master/scripts/mcm-buildall.sh 
invoking https://github.com/richfelker/musl-cross-make as described in 
https://landley.net/toybox/faq.html#cross2

I meant to switch to a more Linux From Scratch style toolchain build, 
but I've been a bit off my game ever since the oldest president ever 
(who had replaced the oldest president ever) decided to run for a second 
term after campaigning on doing one term only. I've found the 
foreseeable consequences distracting and stressful.

Rob

Re: Toybox make root no longer works as expected

[John Paul Adrian Glaubitz]

On Fri, 2026-05-01 at 13:20 -0500, Rob Landley wrote:
> On 4/30/26 02:17, John Paul Adrian Glaubitz wrote:
> > I can give it a try. Would be good if Rob could publish a recent version of the toolchain.
> 
> It's just 
> https://codeberg.org/landley/toybox/src/branch/master/scripts/mcm-buildall.sh 
> invoking https://github.com/richfelker/musl-cross-make as described in 
> https://landley.net/toybox/faq.html#cross2

What about the patches for J2 support? And can it work with a GCC git tree like [1]?

Adrian

> [1] https://github.com/olegendo/gcc/tree/devel/sh-lra

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Toybox make root no longer works as expected

[Rob Landley]

On 5/1/26 13:32, John Paul Adrian Glaubitz wrote:
> On Fri, 2026-05-01 at 13:20 -0500, Rob Landley wrote:
>> On 4/30/26 02:17, John Paul Adrian Glaubitz wrote:
>>> I can give it a try. Would be good if Rob could publish a recent version of the toolchain.
>>
>> It's just
>> https://codeberg.org/landley/toybox/src/branch/master/scripts/mcm-buildall.sh
>> invoking https://github.com/richfelker/musl-cross-make as described in
>> https://landley.net/toybox/faq.html#cross2
> 
> What about the patches for J2 support? And can it work with a GCC git tree like [1]?

They're in musl-cross-make.

https://github.com/richfelker/musl-cross-make/tree/master/patches/binutils-2.44

https://github.com/richfelker/musl-cross-make/tree/master/patches/gcc-9.4.0

Two in each, I think. (Base support and then a later fdpic bugfix.)

Alas, due to the way Rich maintains musl-cross-make (which is INSANE) if 
you want to know WHY any of the patches was added (relevant gcc bugzilla 
entry and so on) you have to find the first release it was added to and 
log THAT patch to find the commit message, because he never puts helpful 
comments at the start of the actual files and the commit where the issue 
was first dealt with is sometimes quite the hunt.

Another reason I wanted to migrate off mcm...

Lemme know if you need me to dig for the source of the fdpic bugfix 
thingies, I knew once but don't have it lying around. (Jeff might?)

Oh, right also invented his own patch applying infrastructure (cowpatch) 
which is like fuzz support but worse: silently eats failures of patches 
to apply. I don't understand why it exists...

Rob

Re: Toybox make root no longer works as expected

[John Paul Adrian Glaubitz]

On Fri, 2026-05-01 at 16:27 -0500, Rob Landley wrote:
> > What about the patches for J2 support? And can it work with a GCC git tree like [1]?
> 
> They're in musl-cross-make.
> 
> https://github.com/richfelker/musl-cross-make/tree/master/patches/binutils-2.44
> 
> https://github.com/richfelker/musl-cross-make/tree/master/patches/gcc-9.4.0
> 
> Two in each, I think. (Base support and then a later fdpic bugfix.)
> 
> Alas, due to the way Rich maintains musl-cross-make (which is INSANE) if 
> you want to know WHY any of the patches was added (relevant gcc bugzilla 
> entry and so on) you have to find the first release it was added to and 
> log THAT patch to find the commit message, because he never puts helpful 
> comments at the start of the actual files and the commit where the issue 
> was first dealt with is sometimes quite the hunt.
> 
> Another reason I wanted to migrate off mcm...
> 
> Lemme know if you need me to dig for the source of the fdpic bugfix 
> thingies, I knew once but don't have it lying around. (Jeff might?)
> 
> Oh, right also invented his own patch applying infrastructure (cowpatch) 
> which is like fuzz support but worse: silently eats failures of patches 
> to apply. I don't understand why it exists...

Hmm, sounds like a bit too much to be able to do that in a short time now
in order to be able to test the kernel patch. I guess I will merge the patch
now anyways and send it to Linus unless someone else has done that already
anyway.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Toybox make root no longer works as expected

[Rob Landley]

On 5/2/26 01:55, John Paul Adrian Glaubitz wrote:
> On Fri, 2026-05-01 at 16:27 -0500, Rob Landley wrote:
>>> What about the patches for J2 support? And can it work with a GCC git tree like [1]?
>>
>> They're in musl-cross-make.
...
> Hmm, sounds like a bit too much to be able to do that in a short time now
> in order to be able to test the kernel patch. I guess I will merge the patch
> now anyways and send it to Linus unless someone else has done that already
> anyway.

The first commit that broke the build was 76b6f5dfb3fd adding the listns 
syscall to kernel/nstree.c which then goes:

during RTL pass: final
In file included from kernel/nstree.c:8:
kernel/nstree.c: In function '__se_sys_listns':
./include/linux/syscalls.h:262:9: internal compiler error: in 
change_address_1, at emit-rtl.c:2275
   262 |         } 
         \
       |         ^
./include/linux/syscalls.h:237:9: note: in expansion of macro 
'__SYSCALL_DEFINEx'
   237 |         __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
       |         ^~~~~~~~~~~~~~~~~
./include/linux/syscalls.h:229:36: note: in expansion of macro 
'SYSCALL_DEFINEx'
   229 | #define SYSCALL_DEFINE4(name, ...) SYSCALL_DEFINEx(4, _##name, 
__VA_ARGS__)
       |                                    ^~~~~~~~~~~~~~~
kernel/nstree.c:729:1: note: in expansion of macro 'SYSCALL_DEFINE4'
   729 | SYSCALL_DEFINE4(listns, const struct ns_id_req __user *, req,
       | ^~~~~~~~~~~~~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
{standard input}: Assembler messages:
{standard input}: Warning: end of file not at end of a line; newline 
inserted
{standard input}:1640: Error: missing operand
{standard input}:1640: Error: invalid operands for opcode
{standard input}:1075: Error: displacement to undefined symbol .L375 
overflows 12-bit field
{standard input}:1113: Error: displacement to undefined symbol .L491 
overflows 12-bit field
{standard input}:1127: Error: displacement to undefined symbol .L376 
overflows 12-bit field
{standard input}:1139: Error: displacement to undefined symbol .L493 
overflows 12-bit field
{standard input}:1173: Error: displacement to undefined symbol .L494 
overflows 12-bit field
{standard input}:1186: Error: displacement to undefined symbol .L286 
overflows 12-bit field
{standard input}:1286: Error: displacement to undefined symbol .L320 
overflows 12-bit field
{standard input}:1300: Error: displacement to undefined symbol .L656 
overflows 12-bit field
{standard input}:1313: Error: displacement to undefined symbol .L499 
overflows 12-bit field
{standard input}:1334: Error: displacement to undefined symbol .L384 
overflows 12-bit field
{standard input}:1359: Error: displacement to undefined symbol .L365 
overflows 12-bit field
{standard input}:1391: Error: displacement to undefined symbol .L385 
overflows 12-bit field
{standard input}:1397: Error: displacement to undefined symbol .L500 
overflows 12-bit field
{standard input}:1409: Error: displacement to undefined symbol .L386 
overflows 12-bit field
{standard input}:1452: Error: displacement to undefined symbol .L346 
overflows 12-bit field
{standard input}:1609: Error: pcrel too far
{standard input}:1611: Error: pcrel too far
{standard input}:1619: Error: pcrel too far
{standard input}:1620: Error: pcrel too far
make[3]: *** [scripts/Makefile.build:287: kernel/nstree.o] Error 1

The end of line not at end of file, missing operand, and invalid 
operands for opcode seem relevant, and the fact it's happening in the 
middle of a nested macro expansion implies that the code being fed into 
the actual compiler plumbing may be nuts here, but I'd have to cc -E and 
then cc -S the result to see what actually happens.

I'm not yet convinced the compiler is WRONG, it may just be missing some 
error checking so it's responding to bad input with shrapnel instead of 
a coherent error message.

Rob

Re: Toybox make root no longer works as expected

[Rob Landley]

On 5/11/26 18:08, Rob Landley wrote:
> The end of line not at end of file, missing operand, and invalid 
> operands for opcode seem relevant, and the fact it's happening in the 
> middle of a nested macro expansion implies that the code being fed into 
> the actual compiler plumbing may be nuts here, but I'd have to cc -E and 
> then cc -S the result to see what actually happens.

The barfing compiler invocation is:

sh2eb-linux-muslfdpic-gcc -nostdinc \
   -I./arch/sh/include -I./arch/sh/include/generated -I./include 
-I./include -I./arch/sh/include/uapi -I./arch/sh/include/generated/uapi 
-I./include/uapi -I./include/generated/uapi -include 
./include/linux/compiler-version.h -include ./include/linux/kconfig.h 
-include ./include/linux/compiler_types.h -D__KERNEL__ -I 
./arch/sh/include/cpu-sh2 -I ./arch/sh/include/cpu-common -I 
./arch/sh/include/mach-common \
   -std=gnu11 -fshort-wchar -funsigned-char -fno-common -fno-PIE 
-fno-strict-aliasing -pipe -m2 -mj2 -mb -mno-fdpic -Wa,-isa=sh2-up 
-ffreestanding -fno-delete-null-pointer-checks -O2 
-fno-allow-store-data-races -fno-stack-protector -fomit-frame-pointer 
-fno-stack-clash-protection -fno-strict-overflow -fno-stack-check 
-fconserve-stack -fno-builtin-wcslen \
   -Wall -Wextra -Wundef -Werror=implicit-function-declaration 
-Werror=implicit-int -Werror=return-type -Werror=strict-prototypes 
-Wno-format-security -Wno-trigraphs -Wno-frame-address 
-Wno-address-of-packed-member -Wmissing-declarations 
-Wmissing-prototypes -Wframe-larger-than=1024 -Wno-main 
-Wvla-larger-than=1 -Wno-pointer-sign -Wcast-function-type 
-Wno-array-bounds -Wno-stringop-overflow -Wno-alloc-size-larger-than 
-Wimplicit-fallthrough=5 -Werror=date-time 
-Werror=incompatible-pointer-types -Werror=designated-init 
-Wenum-conversion -Wunused -Wno-unused-but-set-variable 
-Wno-unused-const-variable -Wno-packed-not-aligned -Wno-format-overflow 
-Wno-format-truncation -Wno-stringop-truncation -Wno-override-init 
-Wno-missing-field-initializers -Wno-type-limits 
-Wno-shift-negative-value -Wno-maybe-uninitialized -Wno-sign-compare 
-Wno-unused-parameter \
   -DKBUILD_MODFILE='"kernel/nstree"' -DKBUILD_BASENAME='"nstree"' 
-DKBUILD_MODNAME='"nstree"' -D__KBUILD_MODNAME=kmod_nstree \
   -c -o kernel/nstree.o kernel/nstree.c

I turned the -c into a -E to get a preprocessed file, and since -E ate 
all the -I and -D you compile THAT with just:

sh2eb-linux-muslfdpic-cc -std=gnu11 -fshort-wchar -funsigned-char 
-fno-common -fno-PIE -fno-strict-aliasing -pipe -m2 -mj2 -mb -mno-fdpic 
-Wa,-isa=sh2-up -ffreestanding -fno-delete-null-pointer-checks -O2 
-fno-allow-store-data-races -fno-stack-protector -fomit-frame-pointer 
-fno-stack-clash-protection -fno-strict-overflow -fno-stack-check 
-fconserve-stack -fno-builtin-wcslen -c nstree-pre.c nstree.o

And even though that says it's barfing on line 1640, which is the 
declaration of raw_atomic_sub_return_relaxed, if you delete all the 
functions after that in the file it doesn't fail. In fact, if I delete 
JUST the last function from the file, it succeeds.

Let's try ripping out some of the decorators:

sed -i -E 
's/__attribute__\(\(__(always_inline|unused|gnu_inline|no_instrument_function|always_inline|warn_unused_result)__\)\)//g' 
nstree-pre2.c

Still dies.

sed -i 's/static inline/static/g' nstree-pre2.c

Still dies.

Hmmm, still a 2.1 megabyte file, bit much to attach here. Let's see...

I switched to -S instead of -c and got

during RTL pass: final
kernel/nstree.c: In function '__se_sys_listns':
kernel/nstree.c:729:3236: internal compiler error: in change_address_1, 
at emit-rtl.c:2275
   729 | SYSCALL_DEFINE4(listns, const struct ns_id_req __user *, req,
       |

Which is because all those "# 123" lines in the -E output, lemme strip 
those and...

nstree-pre2.c:62345:8: warning: 'sys_listns' alias between functions of 
incompatible types 'long int(const struct ns_id_req *, u64 *, size_t, 
unsigned int)' {aka 'long int(const struct ns_id_req *, long long 
unsigned int *, unsigned int,  unsigned int)'} and 'long int(long int, 
long int,  long int,  long int)' [-Wattribute-alias=]

Huh? (I mean it's been doing a lot of warnings because I dropped the 
-Wno-gnu-stupid section, but now we're down to one and it seems 
potentially relevant? Anyway...

during RTL pass: final
nstree-pre2.c: In function '__se_sys_listns':
nstree-pre2.c:62345:3236: internal compiler error: in change_address_1, 
at emit-rtl.c:2275
62345 | d int) > sizeof(long)" " is true");})); do { } while (0); return 
ret; }
       |

3236 is the closing curly bracket on giant line. And again, if I delete 
everyting AFTER that line it works. Stick in a newline at each semicolon 
(and zap the silly #pragma gnu debug pop whatever that is) and... It 
complains that the last curly bracket of the file is the problem now.

I think maybe it's trying to inline __do_sys_listns() into sys_listns() 
but, sticking __attribute__((noinline)) on both the declaration and the 
definition changed nothing. :(

What does kernel/nstree.c do, anyway? It's a large lump of added code 
making the kernel bigger, but there's no config symbol I can switch off 
to remove it (kernel/Makefile has it in obj-y unconditionally). But 
that's modern Linux for you. Bigger and bigger...

Rob

Re: Toybox make root no longer works as expected

[John Paul Adrian Glaubitz]

Hi,

On Sat, 2026-05-02 at 08:55 +0200, John Paul Adrian Glaubitz wrote:
> On Fri, 2026-05-01 at 16:27 -0500, Rob Landley wrote:
> > > What about the patches for J2 support? And can it work with a GCC git tree like [1]?
> > 
> > They're in musl-cross-make.
> > 
> > https://github.com/richfelker/musl-cross-make/tree/master/patches/binutils-2.44
> > 
> > https://github.com/richfelker/musl-cross-make/tree/master/patches/gcc-9.4.0
> > 
> > Two in each, I think. (Base support and then a later fdpic bugfix.)
> > 
> > Alas, due to the way Rich maintains musl-cross-make (which is INSANE) if 
> > you want to know WHY any of the patches was added (relevant gcc bugzilla 
> > entry and so on) you have to find the first release it was added to and 
> > log THAT patch to find the commit message, because he never puts helpful 
> > comments at the start of the actual files and the commit where the issue 
> > was first dealt with is sometimes quite the hunt.
> > 
> > Another reason I wanted to migrate off mcm...
> > 
> > Lemme know if you need me to dig for the source of the fdpic bugfix 
> > thingies, I knew once but don't have it lying around. (Jeff might?)
> > 
> > Oh, right also invented his own patch applying infrastructure (cowpatch) 
> > which is like fuzz support but worse: silently eats failures of patches 
> > to apply. I don't understand why it exists...
> 
> Hmm, sounds like a bit too much to be able to do that in a short time now
> in order to be able to test the kernel patch. I guess I will merge the patch
> now anyways and send it to Linus unless someone else has done that already
> anyway.

Coming back to this. After recent changes to GCC [1], I would expect the chances
to be higher that a J2 toolchain build with GCC 17 would work better when building
a current kernel tree.

Would you be able to help me build a fresh J2 toolchain from the GCC 17 tree?

Thanks,
Adrian

> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Toybox make root no longer works as expected

[D. Jeff Dionne]

I will try and force myself to find time to help with this.

I noticed a few days ago that some very old targets I need to work on are having some bitrot with even new 9.4.0 toolchains.

Rob, can you do me a favour and extract our GCC patch stack for all the sh2 flavours we support cleanly from the build scripts?  All those targets will need forward porting.

Cheers,
J.

> On Jul 12, 2026, at 13:52, Rob Landley <rob@landley.net> wrote:
> 
> On 7/10/26 08:32, John Paul Adrian Glaubitz wrote:
>> Coming back to this. After recent changes to GCC [1], I would expect the chances
>> to be higher that a J2 toolchain build with GCC 17 would work better when building
>> a current kernel tree.
>> Would you be able to help me build a fresh J2 toolchain from the GCC 17 tree?
> 
> Yes, I am interested.
> 
> I was actually poking at that a couple weeks ago. (tl;dr when the arm guys added fdpic support for their target, they broke sh2's fdpic support in commit https://github.com/gcc-mirror/gcc/commit/11189793b6ef and I have a todo item to add some #ifdef __MUSL__ to that since you have to say "sh2eb-blah-muslfdpic" in the config --target anyway).
> 
> Backstory time!
> 
> So I shipped new toolchains with the recent toybox release:
> 
>  https://landley.net/bin/toolchains/19-06-2026/
> 
> This time based on gcc 15.1, and I had to bisect some issues (like https://mstdn.jp/users/landley/statuses/116747488061835417) along the way (the solution of which was for Rich to update musl to the current version in musl-cross-make, which he'd forgotten to do: the system call interface missed annotating two registers as caller saved).
> 
> The one target I _didn't_ get to work in time for the release was sh2eb-fdpic. (With gcc 15.1 the link fails trying to build musl, complaining about being unable to find LP50, every other package can be updated except that one and you get a shell prompt in mkroot, although you seperately have to use an older kernel because of the header assembly issue causing an internal compiler error; that's separate breakage.)
> 
> You still need patches to add proper -mj2 support, but since j2 is backwards compatible with sh2eb-fdpic that's what I've actually been shipping in my toolchains. Unfortunately, sh2-fdpic doesn't work in 15.1, and I bisected from 9.4 to find out why.
> 
> (Drilling forward from "the one that works" to figure out where newer versions broke stuff is my go-to approach when I don't have a firm grasp of the plumbing in question.)
> 
> From my notes;
> 
> The first commit after 9.4 to break fdpic was 5d727a4b2025 which added c++ unwind exception support to arm fdpic. That caused the "unwind-pe.h:270:25: error: '_Unwind_gnu_Find_got' was not declared in this scope" error, which persisted for many, many commits after that...
> 
> Commit 551935d11817 then switched the behavior to the CURRENT failure, the one about LP50. But A) that commit's enormous adding a new subsystem, and B) I think that's a separate error masking the first, not fixing it.
> 
> I was trying to build that toolchain from an unpatched gcc with newer version. (the -mj2 machine is nice to have but not vital, what we _really_ need is sh2eb with fdpic).
> 
> I asked on the #musl irc channel and nsz suggested https://git.zv.io/toolchains/musl-cross-make/-/raw/musl.cc-old/patches/gcc-11-20230427/0100-hack-sh2fdpic-unwind-nonsense.diff?ref_type=heads and with the zv patch and an updated version of the VISIBILITY_HIDDEN patch, commit 551935d11817^1 builds a toolchain! But the resulting toybox segfaults...
> 
> Bisected the segfault to commit 11189793b6ef (back in 2019) where the arm fdpic guys changed the semantics of __do_global_dtors_aux and frame_dummy in a way that broke superh fdpic. They do not explain WHY they changed the semantics' and musl's init code expects the old semantics. (This is one of those crt1.o talking to crtbegin.o talking to crti.o things. The arm guys GLOBALLY changed the handoff, and broke musl-fdpic in the process. I doubt they regression tested fdpic on any other target, and embedded guys always use OLD TOOLCHAINS because the new ones have worse optimizers for C...)
> 
> Seriously, that commit says "we need to make sure __do_global_dtors_aux and frame_dummy are referenced by their address, not by pointers to the function descriptors" but... why? It WORKED BEFORE THAT just fine. You arm guys did not invent fdpic! It's been around for MANY YEARS...
> 
> I've been meaning to get back to this, but I've been juggling too many balls...
> 
> Getting sh2 working with the new optimizer plumbing would e great, but unbreaking fdpic seems like a prerequisite for our use cases...
> 
> Rob

Re: Toybox make root no longer works as expected

[Rob Landley]

On 7/12/26 01:00, D. Jeff Dionne wrote:
> I will try and force myself to find time to help with this.
> 
> I noticed a few days ago that some very old targets I need to work on are having some bitrot with even new 9.4.0 toolchains.
> 
> Rob, can you do me a favour and extract our GCC patch stack for all the sh2 flavours we support cleanly from the build scripts?  All those targets will need forward porting.

For gcc-9.4 there's this in musl-cross-make:

https://github.com/richfelker/musl-cross-make/blob/master/patches/gcc-9.4.0/0007-j2.diff

https://github.com/richfelker/musl-cross-make/blob/master/patches/gcc-9.4.0/0020-sh-fdpic-pr114641.diff

And then binutils-2.44 has:

https://github.com/richfelker/musl-cross-make/blob/master/patches/binutils-2.44/0001-j2.diff

https://github.com/richfelker/musl-cross-make/blob/master/patches/binutils-2.44/0002-sh-fdpic-pr31619.diff

(The second of which is apparently a fix for 
https://sourceware.org/bugzilla/show_bug.cgi?id=31619 and the fix was 
bigger in 2.33.1, I dunno if the last hunk was dropped because it was no 
longer needed or because it didn't apply...)

Then our build scripts add a specs patch:

https://codeberg.org/J-Core/librelane-vhdl-build/src/branch/master/01-toolchains.sh#L25

And you have a patch to add __attribute__ naked:

https://codeberg.org/J-Core/librelane-vhdl-build/src/branch/master/01-toolchains.sh#L212

And then here's the NOMULT patch (which is not properly #ifdeffed but 
chops out stuff when we build a second instance of the compiler, for the 
j1-nomult target):

https://codeberg.org/J-Core/librelane-vhdl-build/src/branch/master/01-toolchains.sh#L332

That's 7 patches in total, 6 of which apply always and the 7th applies 
only when we want to build a j1-nomult compiler. (Cleanup discussion 
stalled because we never worked out what config tuple we wanted to 
specify it, do we need to make it multilib, etc.)

Rob

Re: Toybox make root no longer works as expected

[Florian Fuchs]

On 30 Apr 08:57, John Paul Adrian Glaubitz wrote:
> Hi,
> 
> On Wed, 2026-04-29 at 09:46 +0200, John Paul Adrian Glaubitz wrote:
> > I'm trying to build a new root image after updating Toybox but that no longer works:
> > 
> > glaubitz@node54:/data/home/glaubitz/toybox> make root CROSS=sh2eb-linux-muslfdpic- LINUX=/data/home/glaubitz/sh-linux
> > mkroot/mkroot.sh  -- LINUX=/data/home/glaubitz/sh-linux CROSS=sh2eb-linux-muslfdpic-
> > No ccc symlink to compiler directory.
> > make: *** [Makefile:108: root] Error 1
> > glaubitz@node54:/data/home/glaubitz/toybox>
> > 
> > It asks me to create a "ccc" symlink but I have no clue where that link is supposed
> > to point to. The FAQ says the link is supposed to »pointing at a directory full of
> > cross compilers« but I don't have that and that's not my personal setup. I have the
> > cross compilers installed in my home directory and their bin directories added to
> > the PATH variable which has always worked in the past without any problems.
> > 
> > Can you explain how that "ccc" symlink works?
> 
> OK, for some reason it works now. Unfortunately, the toolchain doesn't like the current kernel:
> 
>   CC      net/ipv4/inetpeer.o
> during RTL pass: final
> In file included from kernel/nstree.c:8:
> kernel/nstree.c: In function '__se_sys_listns':
> ./include/linux/syscalls.h:261:9: internal compiler error: in change_address_1, at emit-rtl.c:2275
>   261 |         }                                                               \
>       |         ^
> ./include/linux/syscalls.h:236:9: note: in expansion of macro '__SYSCALL_DEFINEx'
>   236 |         __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
>       |         ^~~~~~~~~~~~~~~~~
> ./include/linux/syscalls.h:228:36: note: in expansion of macro 'SYSCALL_DEFINEx'
>   228 | #define SYSCALL_DEFINE4(name, ...) SYSCALL_DEFINEx(4, _##name, __VA_ARGS__)
>       |                                    ^~~~~~~~~~~~~~~
> kernel/nstree.c:763:1: note: in expansion of macro 'SYSCALL_DEFINE4'
>   763 | SYSCALL_DEFINE4(listns, const struct ns_id_req __user *, req,
>       | ^~~~~~~~~~~~~~~
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <https://gcc.gnu.org/bugs/> for instructions.
> {standard input}: Assembler messages:
> {standard input}: Warning: end of file not at end of a line; newline inserted
> {standard input}:1592: Error: missing operand
> {standard input}:1592: Error: invalid operands for opcode
> {standard input}:976: Error: displacement to undefined symbol .L339 overflows 12-bit field
> {standard input}:1014: Error: displacement to undefined symbol .L459 overflows 12-bit field
> {standard input}:1028: Error: displacement to undefined symbol .L340 overflows 12-bit field
> {standard input}:1040: Error: displacement to undefined symbol .L461 overflows 12-bit field
> {standard input}:1060: Error: displacement to undefined symbol .L462 overflows 12-bit field
> {standard input}:1082: Error: displacement to undefined symbol .L463 overflows 12-bit field
> {standard input}:1100: Error: displacement to undefined symbol .L252 overflows 12-bit field
> {standard input}:1201: Error: displacement to undefined symbol .L286 overflows 12-bit field
> {standard input}:1211: Error: displacement to undefined symbol .L468 overflows 12-bit field
> {standard input}:1221: Error: displacement to undefined symbol .L298 overflows 12-bit field
> {standard input}:1234: Error: displacement to undefined symbol .L469 overflows 12-bit field
> {standard input}:1256: Error: displacement to undefined symbol .L349 overflows 12-bit field
> {standard input}:1341: Error: displacement to undefined symbol .L314 overflows 12-bit field
> {standard input}:1488: Error: displacement to undefined symbol .L454 overflows 8-bit field 
> {standard input}:1498: Error: displacement to undefined symbol .L471 overflows 8-bit field 
> make[3]: *** [scripts/Makefile.build:289: kernel/nstree.o] Error 1
> make[3]: *** Waiting for unfinished jobs....
> 
> Adrian

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.

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

I got gcc to not ICE, but it then fails with invalid assembler thats why
I became suspicious about the asm in question. 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.

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)); })
 #else
 #define __get_user_u64(x, addr, err) \
 ({ \
@@ -116,7 +116,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)); })
 #endif
 
 #define __put_user_size(x,ptr,size,retval)		\
@@ -196,7 +196,7 @@ __asm__ __volatile__( \
 	".long	1b, 3b\n\t" \
 	".previous" \
 	: "=r" (retval) \
-	: "r" (val), "m" (__m(addr)), "i" (-EFAULT), "0" (retval) \
+	: "r" (val), "o" (__m(addr)), "i" (-EFAULT), "0" (retval) \
         : "memory"); })
 #else
 #define __put_user_u64(val,addr,retval) \
@@ -218,7 +218,7 @@ __asm__ __volatile__( \
 	".long	1b, 3b\n\t" \
 	".previous" \
 	: "=r" (retval) \
-	: "r" (val), "m" (__m(addr)), "i" (-EFAULT), "0" (retval) \
+	: "r" (val), "o" (__m(addr)), "i" (-EFAULT), "0" (retval) \
         : "memory"); })
 #endif
 
-- 
2.43.0

Then there is register clobbering in the sh2 shift helpers, thats a
separate runtime issue.

Regards
Florian

Re: Toybox make root no longer works as expected

[John Paul Adrian Glaubitz]

Hi Florian,

On Tue, 2026-07-14 at 09:47 +0200, Florian Fuchs wrote:
> > OK, for some reason it works now. Unfortunately, the toolchain doesn't like the current kernel:
> > 
> >   CC      net/ipv4/inetpeer.o
> > during RTL pass: final
> > In file included from kernel/nstree.c:8:
> > kernel/nstree.c: In function '__se_sys_listns':
> > ./include/linux/syscalls.h:261:9: internal compiler error: in change_address_1, at emit-rtl.c:2275
> >   261 |         }                                                               \
> >       |         ^
> > ./include/linux/syscalls.h:236:9: note: in expansion of macro '__SYSCALL_DEFINEx'
> >   236 |         __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
> >       |         ^~~~~~~~~~~~~~~~~
> > ./include/linux/syscalls.h:228:36: note: in expansion of macro 'SYSCALL_DEFINEx'
> >   228 | #define SYSCALL_DEFINE4(name, ...) SYSCALL_DEFINEx(4, _##name, __VA_ARGS__)
> >       |                                    ^~~~~~~~~~~~~~~
> > kernel/nstree.c:763:1: note: in expansion of macro 'SYSCALL_DEFINE4'
> >   763 | SYSCALL_DEFINE4(listns, const struct ns_id_req __user *, req,
> >       | ^~~~~~~~~~~~~~~
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See <https://gcc.gnu.org/bugs/> for instructions.
> > {standard input}: Assembler messages:
> > {standard input}: Warning: end of file not at end of a line; newline inserted
> > {standard input}:1592: Error: missing operand
> > {standard input}:1592: Error: invalid operands for opcode
> > {standard input}:976: Error: displacement to undefined symbol .L339 overflows 12-bit field
> > {standard input}:1014: Error: displacement to undefined symbol .L459 overflows 12-bit field
> > {standard input}:1028: Error: displacement to undefined symbol .L340 overflows 12-bit field
> > {standard input}:1040: Error: displacement to undefined symbol .L461 overflows 12-bit field
> > {standard input}:1060: Error: displacement to undefined symbol .L462 overflows 12-bit field
> > {standard input}:1082: Error: displacement to undefined symbol .L463 overflows 12-bit field
> > {standard input}:1100: Error: displacement to undefined symbol .L252 overflows 12-bit field
> > {standard input}:1201: Error: displacement to undefined symbol .L286 overflows 12-bit field
> > {standard input}:1211: Error: displacement to undefined symbol .L468 overflows 12-bit field
> > {standard input}:1221: Error: displacement to undefined symbol .L298 overflows 12-bit field
> > {standard input}:1234: Error: displacement to undefined symbol .L469 overflows 12-bit field
> > {standard input}:1256: Error: displacement to undefined symbol .L349 overflows 12-bit field
> > {standard input}:1341: Error: displacement to undefined symbol .L314 overflows 12-bit field
> > {standard input}:1488: Error: displacement to undefined symbol .L454 overflows 8-bit field 
> > {standard input}:1498: Error: displacement to undefined symbol .L471 overflows 8-bit field 
> > make[3]: *** [scripts/Makefile.build:289: kernel/nstree.o] Error 1
> > make[3]: *** Waiting for unfinished jobs....
> > 
> > Adrian
> 
> 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.
> 
> And errors with libbacktrace, I worked around by --enable-languages=c
> 
> I got gcc to not ICE, but it then fails with invalid assembler thats why
> I became suspicious about the asm in question. 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.
> 
> 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)); })
>  #else
>  #define __get_user_u64(x, addr, err) \
>  ({ \
> @@ -116,7 +116,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)); })
>  #endif
>  
>  #define __put_user_size(x,ptr,size,retval)		\
> @@ -196,7 +196,7 @@ __asm__ __volatile__( \
>  	".long	1b, 3b\n\t" \
>  	".previous" \
>  	: "=r" (retval) \
> -	: "r" (val), "m" (__m(addr)), "i" (-EFAULT), "0" (retval) \
> +	: "r" (val), "o" (__m(addr)), "i" (-EFAULT), "0" (retval) \
>          : "memory"); })
>  #else
>  #define __put_user_u64(val,addr,retval) \
> @@ -218,7 +218,7 @@ __asm__ __volatile__( \
>  	".long	1b, 3b\n\t" \
>  	".previous" \
>  	: "=r" (retval) \
> -	: "r" (val), "m" (__m(addr)), "i" (-EFAULT), "0" (retval) \
> +	: "r" (val), "o" (__m(addr)), "i" (-EFAULT), "0" (retval) \
>          : "memory"); })
>  #endif
>  

Thanks a lot for looking into this, I appreciate the help!

Did you manage to build a J2 toolchain using GCC 17? I have not looked
into it myself yet due to time constraints, but I would like to switch
to a newer compiler to build test kernels for my J2.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Toybox make root no longer works as expected

[Florian Fuchs]

On 14 Jul 10:14, John Paul Adrian Glaubitz wrote:
> Hi Florian,
> 
> On Tue, 2026-07-14 at 09:47 +0200, Florian Fuchs wrote:
> > > OK, for some reason it works now. Unfortunately, the toolchain doesn't like the current kernel:
> > > 
> > >   CC      net/ipv4/inetpeer.o
> > > during RTL pass: final
> > > In file included from kernel/nstree.c:8:
> > > kernel/nstree.c: In function '__se_sys_listns':
> > > ./include/linux/syscalls.h:261:9: internal compiler error: in change_address_1, at emit-rtl.c:2275
> > >   261 |         }                                                               \
> > >       |         ^
> > > ./include/linux/syscalls.h:236:9: note: in expansion of macro '__SYSCALL_DEFINEx'
> > >   236 |         __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
> > >       |         ^~~~~~~~~~~~~~~~~
> > > ./include/linux/syscalls.h:228:36: note: in expansion of macro 'SYSCALL_DEFINEx'
> > >   228 | #define SYSCALL_DEFINE4(name, ...) SYSCALL_DEFINEx(4, _##name, __VA_ARGS__)
> > >       |                                    ^~~~~~~~~~~~~~~
> > > kernel/nstree.c:763:1: note: in expansion of macro 'SYSCALL_DEFINE4'
> > >   763 | SYSCALL_DEFINE4(listns, const struct ns_id_req __user *, req,
> > >       | ^~~~~~~~~~~~~~~
> > > Please submit a full bug report,
> > > with preprocessed source if appropriate.
> > > See <https://gcc.gnu.org/bugs/> for instructions.
> > > {standard input}: Assembler messages:
> > > {standard input}: Warning: end of file not at end of a line; newline inserted
> > > {standard input}:1592: Error: missing operand
> > > {standard input}:1592: Error: invalid operands for opcode
> > > {standard input}:976: Error: displacement to undefined symbol .L339 overflows 12-bit field
> > > {standard input}:1014: Error: displacement to undefined symbol .L459 overflows 12-bit field
> > > {standard input}:1028: Error: displacement to undefined symbol .L340 overflows 12-bit field
> > > {standard input}:1040: Error: displacement to undefined symbol .L461 overflows 12-bit field
> > > {standard input}:1060: Error: displacement to undefined symbol .L462 overflows 12-bit field
> > > {standard input}:1082: Error: displacement to undefined symbol .L463 overflows 12-bit field
> > > {standard input}:1100: Error: displacement to undefined symbol .L252 overflows 12-bit field
> > > {standard input}:1201: Error: displacement to undefined symbol .L286 overflows 12-bit field
> > > {standard input}:1211: Error: displacement to undefined symbol .L468 overflows 12-bit field
> > > {standard input}:1221: Error: displacement to undefined symbol .L298 overflows 12-bit field
> > > {standard input}:1234: Error: displacement to undefined symbol .L469 overflows 12-bit field
> > > {standard input}:1256: Error: displacement to undefined symbol .L349 overflows 12-bit field
> > > {standard input}:1341: Error: displacement to undefined symbol .L314 overflows 12-bit field
> > > {standard input}:1488: Error: displacement to undefined symbol .L454 overflows 8-bit field 
> > > {standard input}:1498: Error: displacement to undefined symbol .L471 overflows 8-bit field 
> > > make[3]: *** [scripts/Makefile.build:289: kernel/nstree.o] Error 1
> > > make[3]: *** Waiting for unfinished jobs....
> > > 
> > > Adrian
> > 
> > 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.
> > 
> > And errors with libbacktrace, I worked around by --enable-languages=c
> > 
> > I got gcc to not ICE, but it then fails with invalid assembler thats why
> > I became suspicious about the asm in question. 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.
> > 
> > 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)); })
> >  #else
> >  #define __get_user_u64(x, addr, err) \
> >  ({ \
> > @@ -116,7 +116,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)); })
> >  #endif
> >  
> >  #define __put_user_size(x,ptr,size,retval)		\
> > @@ -196,7 +196,7 @@ __asm__ __volatile__( \
> >  	".long	1b, 3b\n\t" \
> >  	".previous" \
> >  	: "=r" (retval) \
> > -	: "r" (val), "m" (__m(addr)), "i" (-EFAULT), "0" (retval) \
> > +	: "r" (val), "o" (__m(addr)), "i" (-EFAULT), "0" (retval) \
> >          : "memory"); })
> >  #else
> >  #define __put_user_u64(val,addr,retval) \
> > @@ -218,7 +218,7 @@ __asm__ __volatile__( \
> >  	".long	1b, 3b\n\t" \
> >  	".previous" \
> >  	: "=r" (retval) \
> > -	: "r" (val), "m" (__m(addr)), "i" (-EFAULT), "0" (retval) \
> > +	: "r" (val), "o" (__m(addr)), "i" (-EFAULT), "0" (retval) \
> >          : "memory"); })
> >  #endif
> >  
> 
> Thanks a lot for looking into this, I appreciate the help!
> 
> Did you manage to build a J2 toolchain using GCC 17? I have not looked
> into it myself yet due to time constraints, but I would like to switch
> to a newer compiler to build test kernels for my J2.
> 
> Adrian

Yes, with the O1 workaround in gcc and the above patch, but I did a
shortcut and built a plain sh2eb/fdpic toolchain, so I didn't rebase the
bigger J2 specific patches, only a few lines fdpic specific. So that I
could build a kernel, busybox/toybox with it. As I just wanted to finally
boot a current linux on the J2 Mimas v2 board.

And the ICE in nstree.c/uaccess was still there with gcc-17, that went
away with the above patch.

For the Mimas v2 I also needed to configure some offsets differntly in
the .config/Makefiles [0], but that may be normal. Ah, and it needed the patch
regarding the built-in DTBs, that don't work currently [1] And at
runtime it needed this patch, to prevent the register clobber [2]

[0] Offsets, specific (I guess) to the mimas v2 board, copied from the
    original aboriginal vmlinux image:
     ZERO_PAGE_OFFSET "0x0003F000"
     ENTRY_OFFSET "0x00001000"
     CONFIG_ENTRY_OFFSET "0x00040000"

[1] https://lore.kernel.org/linux-sh/20260711000146.3348854-1-fuchsfl@gmail.com/
[2] https://lore.kernel.org/linux-sh/20260714104147.2016549-1-fuchsfl@gmail.com/

Re: Toybox make root no longer works as expected

[Rob Landley]

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.