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 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
