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

[Rob Landley]

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

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

Rob