[Picolibc] Integrating Picolibc into a GCC toolchain

[Keith Packard]

"R. Diez" <rdiezmail-newlib at yahoo.de> writes:

>> Hrm. Maybe what picolibc should be doing is providing a script that uses
>> a template to create the cross compilation file based off values
>> provided by the user. We need some compilation flags, and the triplet
>> describing the target machine. Maybe that's all we'd need? Once the
>> script creates that file, it would run meson with the remaining flags.
>> [...]
>
> I think that is the way to go. Users should not have to know very much about Meson variables or configuration file syntax.
>
>
>>> crosstool-ng-1.24.0.tar.bz2
>>
>> It's in scripts/build/companion_libs/340-picolibc.sh
>
> Thanks. Apparently, that script did not make it to the latest crosstool-ng release 1.24.0, but it is in Git Master:
>
> https://github.com/crosstool-ng/crosstool-ng/blob/master/scripts/build/companion_libs/340-picolibc.sh
>
> Interestingly enough, that script is already outdated, for it is missing the new setting nm = 'arm-none-eabi-nm' that you mentioned. So that's why I think that such a script should be part of Picolibc.
>
> Your script does not handle escaping/quoting correctly. I could write
> a Bash script with such logic.

It's cmake, so I'm not sure what the requirements are. So far, it
appears to work for those who need it (including Zephyr).

> I am wondering how to define the interface right. How about something like this?
>
> GeneratePicolibcCrossFile.sh my-cross-arm-none-eabi.txt none arm cortex-m3 little arm-none-eabi -g -O2 ...
>
> Or perhaps it would be easier to maintain compatibility in the face of
> future enhancements if we had argument names:

Definitely a better plan, also makes using the script self-documenting.

> GeneratePicolibcCrossFile.sh \
>    --output-file="my-cross-arm-none-eabi.txt" \
>    --system="none" \
>    --cpu-family="arm" \
>    --cpu="cortex-m3" \
>    --endian="little" \
>    --arch="arm-none-eabi" \
>    --target-cflag="-g" \
>    --target-cflag="-O2" \
>    --target-ldflag="-lsomelib" \
>    ...
>
> The standard CPU families are defined here and may be used:
>
> https://mesonbuild.com/Reference-tables.html
>
> But are the operating system name and the CPU name important as far as
> Meson or Picolibc are concerned?

Not that I can tell; I haven't really figured out what all of this
stuff is used for.

> File scripts/cross-clang-riscv64-unknown-elf.txt has one extra setting:
>
> c_ld = '/usr/bin/riscv64-unknown-elf-ld'
>
> Is that really needed?

Yes, otherwise you get clang's default linker, which can't be used for
embedded applications.

> Is it OK to set "needs_exe_wrapper = true" and then not set
> "exe_wrapper"? Your script 340-picolibc.sh does that. Can you leave
> both out if you just want to build Picolibc to be GCC's libc?

Yes, those settings are only needed if you want to run the tests.

> GNU Make makefiles have problems with spaces, and you may want to pass
> flags like [ -Wl,blah -g -O2 -DNAME="Computer's name" ], where some
> flags have quotes and spaces inside.

One area where meson really has a better answer? In any case, if you're
up for creating a script, I'd be more than happy to stick it in the repo
*and* switch the existing scripts to use it (to make sure it continues
to work, testing is very useful)

> Perhaps it would be easier to pass CFLAGS_FOR_TARGET as an environment
> variable. Otherwise, specifying all settings in one or in several
> command-line arguments may be cumbersome or difficult inside a
> makefile.

> What do you think?

I think using command line parameters would probably be cleaner; if
they're labeled, they're self-documenting and don't introduce
potentially conflicting actions if they happen to match environment
variables used elsewhere.

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://keithp.com/pipermail/picolibc/attachments/20220131/c5047f98/attachment.sig>