Search avr-libc path according to avr-gcc installation at first,
then other possible installed pathes.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
There are already test cases
$llvm/clang/test/Driver/avr-ld.c $llvm/clang/test/Driveravr-toolchain.c
and fake avr-gcc inside $llvm/clang/test/Driver/Inputs/basic_avr_tree to support the above two tests.
So there is no need to add new ones.
clang/lib/Driver/ToolChains/AVR.cpp | ||
---|---|---|
457 | Would it be worth encapsulating this logic in an accessor method on GCCInstallation? |
Thanks. I have added some comments about our agreed logic, as discussed in https://reviews.llvm.org/D107672.
I think this way is clear enough.
@mhjacobson Could you please check if my modification also works as expected on your platform ?
Hm... it doesn't, because there aren't enough ..s.
Here's what my directory tree looks like. My gcc install consists of:
/opt/local/bin/avr-gcc-10.3.0 /opt/local/lib/gcc/avr/10.3.0/libgcc.a /opt/local/libexec/gcc/avr/10.3.0/cc1
And avr-libc is at:
/opt/local/avr/lib/libc.a /opt/local/avr/include/stdio.h
It would work if you appended four ..s (which is effectively what GCC does, since it backs up to the "prefix", which in my case is /opt/local/).
Edit: my setup seems to match the one shown in this presentation (see slides titled "Toolchain contents").
Edit 2: it also matches this, namely /opt/local/avr/lib is $(tooldir)/lib
For other examples of using four ..s, look in Gnu.cpp, where there are several places where getParentLibPath() is appended with /../. AddMultilibPaths(), PushPPaths().
getParentLibPath(), in turn, is GCCInstallPath/../../../
Thanks for your help. I have updated my patch. Now it should work for both your platform and mine. It search GCCRoot.getParentLibPath()/avr first, otherwise GCCRoot.getParentLibPath()/../avr.
Please help me check.
Seems a new RUN line is needed. If having too many mock trees are inconvenient, consider clang/unittests/Driver/ToolChainTest.cpp
I am not familiar with the way in clang/unittests/Driver/ToolChainTest.cpp, I always use clang command line than libcall. Though I have created a new test TEST(ToolChainTest, VFSAVRInstallation) by imitating the existing TEST(ToolChainTest, VFSGCCInstallation), it did not work as I expected. So I created a new mock tree basic_avr_tree_2.
And the tests in avr-toolchain.cc should cover all three possible cases
- find avr-libc at AVR-GCC/../../../avr (the case --check-prefix=CHECK1)
- find avr-libc at AVR-GCC/../../../../avr (the case --check-prefix=CHECK2)
- there is not avr-gcc and find avr-libc at SYSROOT/usr/avr (the case --check-prefix=CHECK3)
The file/directory structure in basic_avr_tree_2/opt/local is the same as mhjacobson's machine.
basic_avr_tree_2/opt/local/bin/avr-gcc-10.3.0 basic_avr_tree_2/opt/local/lib/gcc/avr/10.3.0/libgcc.a basic_avr_tree_2/opt/local/avr/ basic_avr_tree_2/opt/local/avr/lib/libc.a basic_avr_tree_2/opt/local/avr/include/.keep
The above is for CHECK2, and there is an avr-libc only structure for CHECK3.
basic_avr_tree_2/usr/avr/ basic_avr_tree_2/usr/avr/lib/libc.a basic_avr_tree_2/usr/avr/include/.keep
Would it be worth encapsulating this logic in an accessor method on GCCInstallation?