[llvm] [clang][Hexagon] Add Picolibc as part of triple (PR #169613)

[via llvm-commits]

quic-k wrote:

> There are some restrictions on what MUSL supports for example ifunc support https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Basic/TargetInfo.h#L1578
> 
> I agree that there isn't any defined rules for when an environment is the right answer or not. There was some concern raised at the dev meeting about the number of possible bare-metal C-libraries that exist and could have environments added for them. I think it would be reasonable to say picolibc, newlib and llvmlibc.
> 
> 
> Instead of switching include and library directories for a specific environment then you have a single -I and -L directory structure (shared between C-libraries) and then change sysroot to switch between C libraries. We support newlib and LLVM libc as an overlay package by installing a sysroot. We then have a config file that sets the sysroot and the same driver works for all 3.
> 
> That wouldn't require a new environment per C-library, just a change of sysroot.
> 
> 
> Yes, I think there is scope to do this better, although for most Drivers the choice of semihosting or not is independent of the environment. Production = no semihosting (no argc/argv and debug IO interface), development = semihosting. Picolibc's default is production with crt0.o no semihosting. It looks like you want to default to semihosting.
> 
> There's always two environments picolibc and picolibc-semihosting but it seems like we're just putting too much into the environment.
> 
> 
> Main reason to split it out into two PRs is that there's two separate decisions here:
> 
>     * Should we add an environment for Picolibc that can be used by any Driver?
> 
>     * What should the Hexagon driver do with the Picolibc environment?
> 
> 
> I can much more easily contribute to reviews that could affect an Arm target. Decisions that are specific to the Hexagon driver are much harder for me to contribute to (as an Arm employee). It may be easier to get approval for the two independently as a smaller number of people are likely to be concerned about Hexagon specific changes.
> 
> I don't think you need to split it, if I'm the only one bothered about it. I just won't be able to comment on anything beyond the environment parts.
> 
> To summarise:
> 
>     * The main downside of adding a picolibc environment is that we'll likely end up with several more environments, I think newlib, newlib-nano and LLVM-libc are likely.
> 

this is true, if we add Picolibc as enviroment type, we will need to add other libc implementations as well, when needed

>     * I think that there are ways to add support for picolibc without using an environment. That would avoid the concern above, for now at least, but I acknowledge that there are design trade-offs that may prefer an environment.

again true, alternative is that user specifies sysroot, crt files, semihost/OS lib explicitly in the command
adding libc to environment or adding a --libc flag will allow the user to switch libraries, I hope other toolchains would want this as well, ARM embedded is one of the major ones

>     * I don't/can't have an opinion on the Hexagon specific parts of the PR.

I will move out the hexagon bits to a separate PR so reviewers can focus on both parts separately

>     * If there is a consensus is that adding an environment for bare-metal C-library is fine, then I don't have any objections, it is not much extra code and there are already examples in the hosted area.

any idea who else we can add here to reach this consensus?



https://github.com/llvm/llvm-project/pull/169613