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

[Rob Landley]

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? :)

> 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...)

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?

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...

Rob