Update libxenon to use GCC16

[mitchellwaite]

This PR makes the following changes to update the compiler in libxenon to GCC 16.2.0:

• New diff for 16.2.0. Mostly the same changes as what we've done for GCC 9.2.0, with the following additions:
  • glibcxx_cv_getentropy and glibcxx_cv_arc4random are disabled since libxenon doesn't provide an implementation of getentropy
• Update build-xenon-toolchain to point to the new tarballs.
• Reduce the following errors to warnings, as GCC16 upgraded the severity
  • -Wno-error=int-conversion -Wno-error=implicit-function-declaration -Wno-error=incompatible-pointer-types
• Set --disable-initfini-array to ensure gcc uses .ctors rather than .init_array for C++ constructors, so existing homebrew works as-is
• Update the elf loader code (set no-tree-loop-distribute-patterns) to resolve trap observed when XeLL attempts to load an elf
• Set -fwrapv for libxenon to prevent GCC from optimizing away integer overflow (which broke the edram init code)

Note: Free60Project/libext2fs#3 is a prereq to this since the ext2 library does need a few tweaks to build clean with GCC16

[InvoxiPlayGames]

Not including issues GCC decided to turn into warning-as-error, does other homebrew, Linux etc build (and more importantly, work) properly with this toolchain?

---

Update the elf loader code (set no-tree-loop-distribute-patterns) to resolve trap observed when XeLL attempts to load an elf

It'd be good to comment where and why this happens for future people to stumble upon, like how it being relocated is commented.

[mitchellwaite]

@InvoxiPlayGames do we have any good example homebrew that we know compiles against the latest version of libxenon?

I may need to make some updates to libxenon/drivers/newlib, though. It looks like there may be a new dependency on getentropy. my ghetto version snes9x fails to compile:

I'll have a look in to that and ping you when i've got an update.

Re: Linux, i was able to compile and boot 6.17 and was also able to boot an existing ArchISO from my flash drive. No issues there.

[mitchellwaite]

So i've finally got snes9x-gx working under the new compiler (There are still some UI problems... GCC 9.2 had those as well), and the cube example also works, but i've run into an issue outside of my wheelhouse-

The new GCC uses .init_array instead of .ctors for C++ static constructors, meaning no C++ constructors are getting called.

--disable-initfini-array reverts the behaviour to be like GCC 9.2 (works), and our AI overlords have come up with a both a hacky linker script that puts everything in .ctors (also works) and a proper fix that makes libxenon look at .init_array sections.

I'll need to do some more research but would like an expert opinion... proper fix would be nice but i'm not familiar with what the implications would be and it's quite late. I'll be able to revisit later this week.

[InvoxiPlayGames]

Personally, I'd rather the simplest option that isn't a hack. Given most of the reasoning for switching to .init_array doesn't quite line up with any of LibXenon's limitations of running on the 360, and we have some amount of C++ homebrew that we'd like to still be compileable as-is, I think --disable-initfini-array is the best way forwards. Would also mean for something like #48, libxenon doesn't need to be hacked up to use either/or depending on compiler version.

[mitchellwaite]

@InvoxiPlayGames pushed a change for --disable-initfini-array, we should be good to go now. I haven't run in to any other issues.

[InvoxiPlayGames]

If you can confirm XeLL stage1 works fine like this then I'll merge.

[mitchellwaite]

If you can confirm XeLL stage1 works fine like this then I'll merge.

Yep, stage 1 works fine. I was able to flash an updxell.bin and boot with no issues.