[PATCH] D33259: Don't defer to the GCC driver for linking arm-baremetal

[Jonathan Roelofs via Phabricator via cfe-commits]

jroelofs planned changes to this revision.
jroelofs added inline comments.


================
Comment at: cmake/caches/BaremetalARM.cmake:1
+set(LLVM_TARGETS_TO_BUILD ARM CACHE STRING "")
+
----------------
compnerd wrote:
> Please rename this file to `BareMetalARMv6.cmake`.  (I'm interested in the suffix primarily).
My plan is to eventually add multilibs to this configuration, so while that makes sense short term, I don't think it makes sense long term.

With that in mind, do you still want me to rename it?


================
Comment at: lib/Driver/ToolChains/BareMetal.cpp:68
+  SmallString<128> Dir(getDriver().ResourceDir);
+  llvm::sys::path::append(Dir, "lib", "baremetal");
+  return Dir.str();
----------------
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.


================
Comment at: lib/Driver/ToolChains/BareMetal.cpp:74
+  SmallString<128> Dir(getDriver().ResourceDir);
+  llvm::sys::path::append(Dir, "include", "c++", "v1");
+  return Dir.str();
----------------
compnerd wrote:
> This seems wrong.  The libc++ headers should *not* be in the resource dir.  This should be based off of the sysroot IMO.
Oh, excellent point. I was just making that same argument a few weeks ago.


================
Comment at: lib/Driver/ToolChains/BareMetal.cpp:107-108
+                                    ArgStringList &CmdArgs) const {
+  CmdArgs.push_back("-lc++");
+  CmdArgs.push_back("-lc++abi");
+  CmdArgs.push_back("-lunwind");
----------------
compnerd wrote:
> I think that this is a bit extreme.  We already have `-stdlib=libc++` and `-stdlib=libstdc++`.  Why not just honor that?
I wasn't going for "support every possible thing out of the tin", instead preferring incremental development :)


https://reviews.llvm.org/D33259