[PATCH] D33259: Don't defer to the GCC driver for linking arm-baremetal
Jonathan Roelofs via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Tue May 23 08:03:37 PDT 2017
jroelofs added inline comments.
Comment at: lib/Driver/ToolChains/BareMetal.cpp:68
+ SmallString<128> Dir(getDriver().ResourceDir);
+ llvm::sys::path::append(Dir, "lib", "baremetal");
+ return Dir.str();
> jroelofs wrote:
> > compnerd wrote:
> > > jroelofs wrote:
> > > > compnerd wrote:
> > > > > Why not just the standard `arm` directory?
> > > > There are a few differences between the stuff in the existing ones, and what is needed on baremetal. For example __enable_execute_stack, emutls, as well as anything else that assumes existence of pthreads support shouldn't be there.
> > > Well, I think that "baremetal" here is a bad idea. How about using the android approach? Use `clang_rt.builtins-arm-baremetal.a` ?
> > Why? Given the way the cmake goop works in lib/runtimes + compiler-rt, the folder name there has to be the same as the CMAKE_SYSTEM_NAME. The alternative, I guess, is to call it 'generic', but I'm not convinced that's better than 'baremetal'.
> Because I can have a baremetal environment that uses a different architecture. How do you differentiate between the MIPS and ARM bare metal runtimes? The way that the compiler actually looks up the builtins is that it uses `clang_rt.[component]-[arch][-variant]`
Yes, and that's still how they're being looked up (and built/installed), even in this patch:
Having arch+variant in the name means they won't intersect, just as they don't for any other system. The only difference here is that baremetal doesn't really have a "system" per se, and it's not appropriate to use the darwin/linux/whatever ones, hence the 'baremetal' folder.
More information about the cfe-commits