Initial picolibc support

[asiekierka]

picolibc offers a number of advantages over newlib, some of which include:

• alternate "tinystdio" stdio implementation, derived from AVR libc, with a significantly smaller code size and no iprintf/printf dual implementation problem (but this has problems, see below)
• standardizing on compiler thread local storage over custom reentrancy structures (albeit this is not necessarily of use to libdragon at this time)
• clearer licensing terms (removal of non-BSD-license-compatible source code)

This pull request provides initial support for picolibc, as an opt-in environment variable N64_USE_PICOLIBC=true when building the toolchain. It also provides, separately, an environment variable N64_USE_PICOLIBC_TINYSTDIO=true to enable the alternate stdio implementation. Without these environment variables, newlib is used as before, with no changes.

TODO:

• picolibc does not yet support the mips64 CPU family addressed here: Add MIPS64 CPU family support. picolibc/picolibc#730
• ~~tinystdio does not implement funopen(), which precludes supporting streaming compressed assets at this time. ~~ picolibc's tinystdio now implements funopen()!
• tinystdio does not implement vasnprintf(), which precludes the stack/heap implementation of rdpq_text_printf. However, this is not necessary; it's solely an optimization strategy, and vasprintf() works just fine. picolibc's tinystdio now implements vasnprintf()!
• It seems some programs crash; fewer crash with -Dnewlib-global-errno=true passed. Is thread-local storage enabled early enough?

[asiekierka]

    [LD] build/test.elf
      text       data        bss      total filename
    111416      67852       2968     182236 build/test.elf
# picolibc (tinystdio off)
# the difference here is at least in large part due to disabling reentrancy - which wasn't used
# by libdragon anyway, and picolibc standardizes everything on compiler TLS
    [LD] build/test.elf
      text       data        bss      total filename
     94568      67196       3480     165244 build/test.elf
# picolibc (tinystdio on)
    [LD] build/test.elf
      text       data        bss      total filename
     75496      66292       3816     145604 build/test.elf
# picolibc (tinystdio on, minimal integer-only printf)
    [LD] build/test.elf
      text       data        bss      total filename
     69064      65380       3816     138260 build/test.elf

[keith-packard]

vasnprintf is a newlib extension not even present in glibc; is there some reason vasprintf isn't sufficient for your use?
funopen is coming soon.

[asiekierka]

There's no reason vasprintf is not sufficient for libdragon's usecase. vasnprintf is solely used for an optimization where a 512-byte stack buffer is allocated first, then a heap allocation is only made in the unlikely event that vsnprintf creates a larger string. This is far from essential.

[rasky]

This is far from essential.

It's a hot code path though. We would have to change that to vsnprintf first and if that fails, use vasprintf, which is a pity because you've to redo the whole formatting. To be fair, the case where it doesn't fit 512 bytes is cold/unlikely so maybe it doesn't matter much.

[keith-packard]

Makes sense. I think you could pretty easily build an implementation of the vasnprintf API using vsnprintf and vasprintf which did exactly that at modest cost in code space. It seems like using standard interfaces in your application would have some modest readability benefits at least. vasnprintf is not precisely documented in the newlib code, although the semantics seem fairly obvious.

[asiekierka]

Rebased with the latest preview branch; funopen() support integrated. This means the PR is probably ready for review.

[asiekierka]

Rebased again.

[keith-packard]

Just for you, I added picolibc/picolibc#885

[asiekierka]

Oh, I modified the PR not to require it months ago, but thank you!

[keith-packard]

I figured the rest of the group would be happier to not have that regression :-)

[keith-packard]

(also found that I wasn't testing asprintf at all (oops!))

[asiekierka]

After discussing on the Discord, we'll try to get the PR evaluated and merged in late December, after this year's N64 Jam is over.

[asiekierka]

Retested. The picolibc advantage is less significant now that libdragon is threaded, but removing _reent does simplify things a little.

    [LD] build/test.elf
      text       data        bss      total filename
    128280      23016       3572     154868 build/test.elf
# picolibc (tinystdio off)
    [LD] build/test.elf
      text       data        bss      total filename
    107768      22356       4104     134228 build/test.elf
# picolibc (tinystdio on)
    [LD] build/test.elf
      text       data        bss      total filename
     86840      21484       4412     112736 build/test.elf
# picolibc (tinystdio on, minimal integer-only printf)
# LDFLAGS += --defsym=vfprintf=__i_vfprintf --defsym=vfscanf=__i_vfscanf
    [LD] build/test.elf
      text       data        bss      total filename
     81896      20644       4412     106952 build/test.elf

[asiekierka]

picolibc should be frozen at commit b4faae61ae49e26078a64f2f6b31e24fe1f33cc2 (January 3rd) for now, as the commits after that lead up to removing Doug Lea's dlmalloc in favor of a much simpler (but most likely worse for complex allocation scenarios) malloc implementation.

I am entertaining porting either a newer version of dlmalloc, or the TLSF allocator, on top. If you have any better ideas worth evaluating, let me know.

[keith-packard]

I am entertaining porting either a newer version of dlmalloc, or the TLSF allocator, on top. If you have any better ideas worth evaluating, let me know.

Note that you can simply copy the newlib malloc code into your project directly and replace the picolibc malloc code that way. Picolibc cannot depend upon its own malloc implementation as many projects replace that with their own.

[asiekierka]

Good to know that it's supported to do so - thank you!

[asiekierka]

It turns out dlmalloc 2.8.6 slots right in.

[keith-packard]

Good to know that it's supported to do so - thank you!

Yup, and this gets tested as a part of Zephyr integration on a regular basis.

[rasky]

Thanks for the heads up. In N64 land, we would need a few extensions to dlmalloc, in particular we would need a way to hint what part of the heap (address range) try to fit some specific allocations, because there are performance issues when multiple hardware devices access memory areas that are too close together. This is not supported by dlmalloc as-is so I guess a fork is needed anyway

[asiekierka]

If a 3-clause BSD license is not of concern to you, you can also try forking the tlsf allocator, which is held in high regard. Or you can try implementing your own allocator! Either way, the above dlmalloc implementation example should help with that.