Hi,
> > > > The default sh-elf configuration has no multi-libs for SH3 and SH4 > > > > variants > > > > without FPU (from what I can see). So it won't use soft-fp so much > > > > during > > > > sim testing. So please change to soft-fp for sh*, not just SH3/SH4. > > > > Got it, done that locally, and will update patch once tested. > > > > > > Here's an old proposed change to the simtest instructions to not use > > > > combined trees: > > > > > > > > https://gcc.gnu.org/pipermail/gcc-patches/attachments/20140815/fb38918e/attachment.bin > > > > Thanks for the instructions. Apologies for the back-and-forth as I'm > > pretty new with this infrastructure (I usually do research stuff on LLVM). No need to apologize. I know this is a tedious and annoying thing to go through and there is only very little useful information out there. > > The split-tree build goes better, still fails with GCC 15 (as expected, > > though somehow my custom toolchain did build originally) and sort of > > works with GCC 14. > > The binutils/gdb repos have been merged since that attachement, and > > while I can build binutils only with --disable-gdb, building gdb (in > > another build folder, reconfiguring from scratch) seems iffy. The global > > CFLAGS/CXXFLAGS to switch to 32-bit affects at least parts of binutils, > > resulting in a broken toolchain due to architecture mixup: It shouldn't be needed to build GDB separately or to specify the -m32 flags. Not sure why you have to do that. I've just tried the following configure lines: binutils-gdb (binutils-2_41-release) <..>/configure --target=sh-elf --prefix=/usr/local --disable-nls --disable-werror --enable-initfini-array gcc (any version) <..>/configure --target=sh-elf --prefix=/usr/local --enable-languages=c,c++,lto --disable-nls --disable-werror --with-newlib --enable-lto --enable-multilib --with-system-zlib --disable-libstdcxx-verbose --disable-symvers newlib (latest) CFLAGS_FOR_TARGET="-Wno-error=implicit-function-declaration -Wno-implicit-int -ffunction-sections -fdata-sections -flto" <..>/newlib/configure --host=sh-elf --target=sh-elf --prefix=/usr/local --enable-multilib --enable-newlib-io-c99-formats Note that the latest newlib version will try to create multilib directories one directory above its current build directory for some reason. So just create another sub-directory in the build directory and do the config and build from there. Other than that, the build steps are the same as before. I could reproduce the issue with the latest GCC when building libstdc++. I'm working on a fix for it. Unfortunately I'm also getting the SIGBUS error when running a C++ program that uses std::cout / std::cerr. To be honest, I don't remember what the issue was/is, whether this has ever worked at all or not. I've tried rewinding everything back ~10 years ago but was still getting the same error. Using printf from the simulator seems to work fine though. So I guess a bunch of C++ tests of the GCC testsuite will fail on the simulator, but that could be tolerable -- it never passed all the tests on the simulator anyway. It's still a good way to test for regressions that could be introduced by a patch. > > How active are the main types? Like are there still new products > > designed with these (maybe the J2)? There is some activity on the software side which mainly stems from folks using old parts and systems. I'd say the biggest activity is now people hammering on Sega 32X (SH2), Saturn (SH2) and Dreamcast (SH4), but I might be biased here. As for new hardware, I'm not sure. Apparently it's still possible to license SH4A(+FPU) and SH4AL-DSP IP cores from Renesas, but I doubt anybody is really doing that. Some parts are still being manufactured, like SH2A for some niche applications. Don't know what j-core people are up to these days. Some of the SH MCUs have been re-implemented as open source gateware for the MisTer FPGA project. > > > > I'd be interested to learn more about the history of the SH backend, if > > anyone wrote that up somewhere... > > >From what I know it started during the earlier cygwin days in the 90s, originally contracted by Hitachi to complement their own in-house C compiler and also to allow sh-linux to happen at some point. It was entertained by Renesas for a while through further contracted support work but eventually they have abandoned it. STmicro was also a licensee of the SH4 CPU for their TV set top boxes and had a few guys submitting patches now and then for a while. But the whole thing basically went on life support about 10 years ago. Perhaps Jeff or others can give more insight on the historical parts. Best regards, Oleg Endo
