Picolibc

[aykevl]

This is necessary for better CGo support on bare metal. Existing libraries expect to be able to include parts of libc and expect to be able to link to those symbols.

Because with this all targets have a working libc, it is now possible to add tests to check that a libc in fact works basically.

Not all parts of picolibc are included, such as the math or stdio parts. These should be added later, when needed.

This PR also avoids the need for the custom memcpy/memset/memcmp symbols that are sometimes emitted by LLVM. The C library will take care of that.

(The first commit is basically #849).

[aykevl]

I've looked at several libraries and I think this is the best one for our purposes. Other libraries I've looked at:

• Newlib: big and originally not intended for bare metal.
• EmbeddedArtistry libc: little used and possibly incomplete. Also contains lots of submodules, which can be inconvenient.

Further information:
https://keithp.com/blogs/picolibc/
https://www.youtube.com/watch?v=SC6aBezNFFQ

[aykevl]

Looks like it'll need an improvement for macOS:

        --- FAIL: TestCompiler/Host/cgo (1.64s)
            main_test.go:136: failed to build: /usr/include/secure/_string.h:82:20: unexpected token ILLEGAL

[aykevl]

The problem was that functions like strcpy were replaced by __builtin___strcpy_chk for _FORTIFY_SOURCE. I don't think it's sensible to use source code fortification in the CGo layer so I simply disabled it. It is still kept at the default value for C files bundled in packages (such as testdata/cgo/main.c).

This PR is now ready for review.

[bgould]

Would it make sense to set a build tag for the libc implementation that is used? For example I am trying to implement malloc() and free() in the runtime and it might be useful to be able to protect that with a build tag. I think for now I can do it with the build tags for cortex-m/riscv/gba, but that might be a little fragile in the long run.

[aykevl]

I'm not sure what you mean. Why would you need a build tag? It's not the C library that defines these functions but the C specification (just like with memset etc).

You can use the baremetal build tag to exclude these functions from targets like WebAssembly and Linux. However, I think renaming these functions to malloc etc would be the better solution. Not sure yet.

[deadprogram]

@aykevl I suggest rebasing against dev again, since there have been quite a few changes since the last time it was done.

[aykevl]

Okay, rebased.

[deadprogram]

Now merging, as this does seem to be the best option.

[aykevl]

Great!