[J-core] Did anybody do anything with those turtle boards?

[Patrick Oppenlander]

On Fri, Jun 25, 2021 at 8:42 PM Rob Landley <rob at landley.net> wrote:
>
> On 6/23/21 7:36 PM, Patrick Oppenlander wrote:
> > On Wed, Jun 23, 2021 at 10:14 PM Rob Landley <rob at landley.net> wrote:
> >>
> >> On 6/17/21 11:51 PM, Patrick Oppenlander wrote:
> >> > On Fri, Jun 18, 2021 at 2:50 PM Patrick Oppenlander
> >> > <patrick.oppenlander at gmail.com> wrote:
> >> >>
> >> >> On Thu, Jun 17, 2021 at 9:17 PM Rob Landley <rob at landley.net> wrote:
> >> >> >
> >> >> > Anyway: yes please, send me the patch. It will annoy Jeff.
> >> >>
> >> >> Attached.
> >> >>
> >> >
> >> > Actually attached this time. Sorry.
> >>
> >> It's mostly removing underscores from symbol names, adding a CROSS_COMPILE
> >> prefix (something Rich and I have both pointed out the need for)...
> >>
> >> -OUTPUT_FORMAT("elf32-sh")
> >> -OUTPUT_ARCH(sh)
> >>
> >> Why did those need to be yanked from the linker script? (Unnecessary, or did
> >> they cause a problem?)
> >
> > Managed to dig up the toolchain I was using, which happened to be
> > sh2eb-linux-musl.
>
> Huh. The ones I build with toybox's scripts/mcm-buildall.sh produce
> sh2eb-linux-muslfdpic-cross/bin/sh2eb-linux-muslfdpic-*
>
> I've made puppy eyes at Rich about having releases for musl-cross-make, but alas
> he uses the "continuous integration" method of not guaranteeing any two users
> will ever quite see the same results because git snapshot du jour is your only
> option. (Is it too much to tag some commits that a human actually personally tried?)
>
> That said, he just did his first commit to the repository in 7 months yesterday,
> so I'm _guessing_ you were using the October 1, 2020 version? :)

It was probably a random point in my tree here -- I've been working on
teaching mcm to build a clang toolchain so I've got quite a few
changes in my mcm tree.

> > sh2eb-linux-musl-ld: target elf32-sh not found
>
> I have no idea how you built it. What I have lying around is:
>
> $ bin/sh2eb-linux-muslfdpic-cc -v
> Using built-in specs.
> COLLECT_GCC=bin/sh2eb-linux-muslfdpic-cc
> COLLECT_LTO_WRAPPER=/home/landley/mcm/clean/ccc/sh2eb-linux-muslfdpic-cross/bin/../libexec/gcc/sh2eb-linux-muslfdpic/9.2.0/lto-wrapper
> Target: sh2eb-linux-muslfdpic
> Configured with: ../src_gcc/configure --enable-languages=c,c++ --enable-fdpic
> --enable-twoprocess CFLAGS=' -g0 -Os' CXXFLAGS=' -g0 -Os' LDFLAGS=' -s'
> CC='i686-linux-musl-gcc -static --static' CXX='i686-linux-musl-g++ -static
> --static' --disable-nls --disable-libquadmath --disable-decimal-float
> --disable-multilib --enable-languages=c,c++ --with-cpu=mj2 --disable-bootstrap
> --disable-assembly --disable-werror --target=sh2eb-linux-muslfdpic --prefix=
> --libdir=/lib --disable-multilib --with-sysroot=/sh2eb-linux-muslfdpic
> --enable-tls --disable-libmudflap --disable-libsanitizer
> --disable-gnu-indirect-function --disable-libmpx --enable-libstdcxx-time=rt
> --with-build-sysroot=/home/landley/mcm/clean/build/local/sh2eb-linux-muslfdpic/obj_sysroot
> AR_FOR_TARGET=/home/landley/mcm/clean/build/local/sh2eb-linux-muslfdpic/obj_binutils/binutils/ar
> AS_FOR_TARGET=/home/landley/mcm/clean/build/local/sh2eb-linux-muslfdpic/obj_binutils/gas/as-new
> LD_FOR_TARGET=/home/landley/mcm/clean/build/local/sh2eb-linux-muslfdpic/obj_binutils/ld/ld-new
> NM_FOR_TARGET=/home/landley/mcm/clean/build/local/sh2eb-linux-muslfdpic/obj_binutils/binutils/nm-new
> OBJCOPY_FOR_TARGET=/home/landley/mcm/clean/build/local/sh2eb-linux-muslfdpic/obj_binutils/binutils/objcopy
> OBJDUMP_FOR_TARGET=/home/landley/mcm/clean/build/local/sh2eb-linux-muslfdpic/obj_binutils/binutils/objdump
> RANLIB_FOR_TARGET=/home/landley/mcm/clean/build/local/sh2eb-linux-muslfdpic/obj_binutils/binutils/ranlib
> READELF_FOR_TARGET=/home/landley/mcm/clean/build/local/sh2eb-linux-muslfdpic/obj_binutils/binutils/readelf
> STRIP_FOR_TARGET=/home/landley/mcm/clean/build/local/sh2eb-linux-muslfdpic/obj_binutils/binutils/strip-new
> --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
> Thread model: posix
> gcc version 9.2.0 (GCC)
>
> With the usual "absolute paths gratuitously baked into the binary for posterity"
> because gcc and fsf.
>
> And yes, the kernel builds find with the fdpic toolchain. (There's some sort of
> -fnofdpic option.)
>
> Given the absence of fdpic support in yours, I'm guessing you're building static
> PIE binaries? Which work on nommu, they just don't let you decouple the 4
> segments code/data/rss/bss so the two writeable ones can fit into small chunks
> of available space and the two read-only ones can be shared between instances of
> the program. (Thus if you run 5 instances of bash you've loaded 5 seperate
> instances of the bash executable into memory because in static PIE there's a
> single base pointer that all four segments are accessed relative to, so your
> rodata is glued to your text and your data is glued to your rodata, and then bss
> is at the end of those three...)

fdpic is nice. Unfortunately when I try to build sh2eb-linux-muslfdpic
with my current mcm I get:

In file included from ../../../../src_gcc/libstdc++-v3/libsupc++/eh_call.cc:32:
/home/patrick/src/toolchain/musl-cross-make/build/local/sh2eb-linux-muslfdpic/src_gcc/libstdc++-v3/../libgcc/unwind-pe.h:
In function 'const unsigned char*
read_encoded_value_with_base(unsigned char, _Unwind_Ptr, const
unsigned char*, _Unwind_Ptr*)':
/home/patrick/src/toolchain/musl-cross-make/build/local/sh2eb-linux-muslfdpic/src_gcc/libstdc++-v3/../libgcc/unwind-pe.h:270:25:
error: '_Unwind_gnu_Find_got' was not declared in this scope
  270 |               result += _Unwind_gnu_Find_got ((_Unwind_Ptr) u);
      |                         ^~~~~~~~~~~~~~~~~~~~

I know, c++ crap, but a toolchain without c++ is not useful to me.

> By the way, did you know the sparc kernel is static pie? It relocates itself on
> boot. Ask me how I know!
>
>   https://lkml.org/lkml/2011/12/14/324
>
> I break everything...
>
> > % sh2eb-linux-musl-ld -V
> > GNU ld (GNU Binutils) 2.33.1
> >   Supported emulations:
> >    shelf_linux
> >    shelf_fd
>
> Yup, got that. (My ld is 2.32 but other than that...)
>
> > But..
> >
> > % sh2eb-linux-musl-objdump -x output/turtle_1v1/boot.elf
> > output/turtle_1v1/boot.elf:     file format elf32-shbig-linux
>
> I dunno where you got your toolchain.
>
> Once upon a time Zach Van Rijn hosted binary versions of the mcm-buildall.sh
> toolchains on http://b.zv.io/mcm/bin/ but then he got tired of doing that and
> moved them to https://mkroot.musl.cc/latest (which were different versions built
> by a different script, which may or may not have worked like the previous
> versions), and now THAT page says THOSE are obsolete and we should get a third
> set of toolchains from a different place. Meanwhile you can still download
> https://busybox.net/downloads/busybox-1.2.1.tar.bz2 which I uploaded there
> fifteen years ago from the same URL because some people like have a known
> behavior reference version to regression test against. (Did I break my
> environment, did new versions of the tool stop working, or was it always like
> this and my invocation's wrong?)
>
> *shrug* Unfortunately GPLv3 is a proprietary license so I don't post binaries,
> but I'm using the sh2eb-linux-muslfdpic-cross toolchain
> (CROSS_COMPILE=sh2eb-linux-muslfdpic-) built using the instructions at
> https://landley.net/toybox/faq.html#cross2 and that works for me?
>
> > I haven't dug further yet.
> >
> >> -LIBGCC += $(shell $(CC) -print-file-name=libgcc-Os-4-200.a)
> >>
> >> I very vaguely recall that was left over from a binflt toolchain or some such.
> >> (We were building this with gcc 3.x toolchains at one point. Alas, that history
> >> wasn't exported from mercurial to the git repository, so I'm just guessing...)
> >>
> >> -NEED_LIBC := 0
> >> +NEED_LIBC := 1
> >>
> >> That's mildly awkward: those are derived symbols initialized to zero and then
> >> set to 1 based on other symbols being set, ala:
> >>
> >> # Do we need UART support?
> >> ifeq ($(CONFIG_BOOT0),1)
> >>         NEED_UART := 1
> >> endif
> >> ifeq ($(CONFIG_GDB_STUB),1)
> >> # GDB stub always needs UARTs
> >>         NEED_UART := 1
> >> endif
> >> ifneq ($(CONFIG_TEST_MEM),0)
> >>         NEED_LIBC := 1
> >> endif
> >>
> >> What specifically is it that needs a libc symbol that wasn't getting pulled in
> >> otherwise? If it's always needed, then this bit:
> >>
> >> ifeq ($(NEED_LIBC),1)
> >>         LIBS += lib/libc.a
> >> endif
> >>
> >>
> >> Should probably have the ifeq/endif removed?
> >
> > Setting NEED_LIBC=1 was a quick hack to get it to link.
> >
> > sh2eb-linux-musl-ld: files/pff.o: in function `follow_path':
> > pff.c:(.text+0x430): undefined reference to `memset'
>
> That's a regression, but I dunno if it's toolchain version skew or what?

The gcc docs say

"Most of the compiler support routines used by GCC are present in
'libgcc', but there are a few exceptions.  GCC requires the freestanding
environment provide 'memcpy', 'memmove', 'memset' and 'memcmp'."

The boot build doesn't pass "-ffreestanding" but I can only assume gcc
makes (at least) the same assumptions for a hosted environment.

> That said, if we're feeding it a .a file it should only ever pull in the symbols
> it needs out of it so I dunno why we don't just always do that? Hmmm...

Yup.

These days I build almost everything with LTO switched on which I find
does a good job of reducing code size.

Patrick