-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial picolibc support #535
base: preview
Are you sure you want to change the base?
Conversation
d660a22
to
e4ecd7d
Compare
|
vasnprintf is a newlib extension not even present in glibc; is there some reason vasprintf isn't sufficient for your use? |
There's no reason |
It's a hot code path though. We would have to change that to |
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. |
e4ecd7d
to
32caa84
Compare
Rebased with the latest |
32caa84
to
f93520d
Compare
Rebased again. |
Just for you, I added picolibc/picolibc#885 |
Oh, I modified the PR not to require it months ago, but thank you! |
I figured the rest of the group would be happier to not have that regression :-) |
(also found that I wasn't testing asprintf at all (oops!)) |
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. |
a166170
to
981a84b
Compare
Retested. The picolibc advantage is less significant now that libdragon is threaded, but removing
|
981a84b
to
dd27dbc
Compare
dd27dbc
to
2368351
Compare
picolibc offers a number of advantages over newlib, some of which include:
iprintf
/printf
dual implementation problem (but this has problems, see below)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 variableN64_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 theaddressed here: Add MIPS64 CPU family support. picolibc/picolibc#730mips64
CPU familyfunopen()
, which precludes supporting streaming compressed assets at this time. ~~ picolibc's tinystdio now implementsfunopen()
!tinystdio does not implementpicolibc's tinystdio now implementsvasnprintf()
, which precludes the stack/heap implementation ofrdpq_text_printf
. However, this is not necessary; it's solely an optimization strategy, andvasprintf()
works just fine.vasnprintf()
!-Dnewlib-global-errno=true
passed. Is thread-local storage enabled early enough?