Re: Toybox make root no longer works as expected

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 ha=
ving 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 f=
lavours we support cleanly from the build scripts?  All those targets will n=
eed forward porting.

Cheers,
J.

> On Jul 12, 2026, at 13:52, Rob Landley <[email protected]> wrote:
>=20
> =EF=BB=BFOn 7/10/26 08:32, John Paul Adrian Glaubitz wrote:
>> Coming back to this. After recent changes to GCC [1], I would expect the c=
hances
>> 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 t=
ree?
>=20
> Yes, I am interested.
>=20
> 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 com=
mit https://github.com/gcc-mirror/gcc/commit/11189793b6ef and I have a todo i=
tem to add some #ifdef __MUSL__ to that since you have to say "sh2eb-blah-mu=
slfdpic" in the config --target anyway).
>=20
> Backstory time!
>=20
> So I shipped new toolchains with the recent toybox release:
>=20
>  https://landley.net/bin/toolchains/19-06-2026/
>=20
> 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 solu=
tion of which was for Rich to update musl to the current version in musl-cro=
ss-make, which he'd forgotten to do: the system call interface missed annota=
ting two registers as caller saved).
>=20
> The one target I _didn't_ get to work in time for the release was sh2eb-fd=
pic. (With gcc 15.1 the link fails trying to build musl, complaining about b=
eing 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 a=
n older kernel because of the header assembly issue causing an internal comp=
iler error; that's separate breakage.)
>=20
> You still need patches to add proper -mj2 support, but since j2 is backwar=
ds 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 f=
rom 9.4 to find out why.
>=20
> (Drilling forward from "the one that works" to figure out where newer vers=
ions broke stuff is my go-to approach when I don't have a firm grasp of the p=
lumbing in question.)
>=20
> =46rom my notes;
>=20
> 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 p=
ersisted for many, many commits after that...
>=20
> 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.
>=20
> I was trying to build that toolchain from an unpatched gcc with newer vers=
ion. (the -mj2 machine is nice to have but not vital, what we _really_ need i=
s sh2eb with fdpic).
>=20
> I asked on the #musl irc channel and nsz suggested https://git.zv.io/toolc=
hains/musl-cross-make/-/raw/musl.cc-old/patches/gcc-11-20230427/0100-hack-sh=
2fdpic-unwind-nonsense.diff?ref_type=3Dheads and with the zv patch and an up=
dated version of the VISIBILITY_HIDDEN patch, commit 551935d11817^1 builds a=
 toolchain! But the resulting toybox segfaults...
>=20
> Bisected the segfault to commit 11189793b6ef (back in 2019) where the arm f=
dpic 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 seman=
tics' and musl's init code expects the old semantics. (This is one of those c=
rt1.o talking to crtbegin.o talking to crti.o things. The arm guys GLOBALLY c=
hanged the handoff, and broke musl-fdpic in the process. I doubt they regres=
sion tested fdpic on any other target, and embedded guys always use OLD TOOL=
CHAINS because the new ones have worse optimizers for C...)
>=20
> Seriously, that commit says "we need to make sure __do_global_dtors_aux an=
d frame_dummy are referenced by their address, not by pointers to the functi=
on descriptors" but... why? It WORKED BEFORE THAT just fine. You arm guys di=
d not invent fdpic! It's been around for MANY YEARS...
>=20
> I've been meaning to get back to this, but I've been juggling too many bal=
ls...
>=20
> Getting sh2 working with the new optimizer plumbing would e great, but unb=
reaking fdpic seems like a prerequisite for our use cases...
>=20
> Rob