This enables layering baremetal multilibs on top of each other.
For example a multilib containing only a no-exceptions libc++ could be
layered on top of a multilib containing C libs. This avoids the need
to duplicate the C library for every libc++ variant.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
| Time | Test | |
|---|---|---|
| 100 ms | x64 debian > Clang.Driver::mips-mti-linux.c |
Event Timeline
I've set approved from the Arm side. Please leave some time for people in the US time zone to leave any final comments or ask for extensions.
| clang/lib/Driver/ToolChains/BareMetal.cpp | ||
|---|---|---|
| 228 | Can you use llvm::reverse instead of allocating an entire new collection? | |
Rebase
| clang/lib/Driver/ToolChains/BareMetal.cpp | ||
|---|---|---|
| 228 | Changed to return an iterator range. | |
| clang/lib/Driver/ToolChains/BareMetal.cpp | ||
|---|---|---|
| 246–250 | What's the reason for returning an empty Multilib, could we instead return and empty range? | |
Rebase
| clang/lib/Driver/ToolChains/BareMetal.cpp | ||
|---|---|---|
| 246–250 | This is for consistency with the previous behaviour, which would fall back to using a default sysroot if no matching multilib was found. | |
LGTM
| clang/lib/Driver/ToolChains/BareMetal.cpp | ||
|---|---|---|
| 240–244 | It should be possible to simplify this with llvm::reverse. | |
| 248–250 | It should be possible to simplify this with llvm::reverse. | |
| clang/lib/Driver/ToolChains/BareMetal.h | ||
| 76 | I'd define an alias for this type with using to avoid repeating it multiple times. | |
I'd define an alias for this type with using to avoid repeating it multiple times.