- Support the multilib layout used by the mips-img-linux-gnu
- Recognize mips{,64}{,el}-img-linux-gnu as being aliases of mips-img-linux-gnu
- Use the correct dynamic linker for mips-img-linux-gnu
- Make mips32r6/mips64r6 the default CPU for mips-img-linux-gnu
Details
Diff Detail
Event Timeline
I'm still working on the test case but I thought it would be sensible to upload the patch anyway so you can look at it sooner.
Some notes are below:
lib/Driver/ToolChains.cpp | ||
---|---|---|
1937 | Before call findMIPSMultilibs() we check that the current architecture is mips or mipsel or mips64 or mips64el. So the first four conditions are redundant here. | |
lib/Driver/Tools.cpp | ||
7036 | We do not need to check that getOS() == llvm::Triple::Linux here. The getLinuxDynamicLinker() function is called on Linux only. | |
7043 | Is the path prefix /lib correct? Maybe /lib64? |
A couple more comments.
lib/Driver/ToolChains.cpp | ||
---|---|---|
1943 | I think we can replace the getEnvironment() == llvm::Triple::GNU condition by the corresponding assert. Should we catch the case when user provide something like mips-img-linux-android? | |
lib/Driver/Tools.cpp | ||
7035 | Are there any toolchains except the mips-img-linux-gnu which use the ld-linux-mipsn8.so.1 dynamic linker? If there is no such toolchains I suggest to write all these conditions as follows: else if (ToolChain.getArch() == llvm::Triple::mips || ToolChain.getArch() == llvm::Triple::mipsel || ToolChain.getArch() == llvm::Triple::mips64 || ToolChain.getArch() == llvm::Triple::mips64el) { if (ToolChain.getTriple().getVendor() == llvm::Triple::ImaginationTechnologies) { assert(ToolChain.getTriple().getEnvironment() == llvm::Triple::GNU && "Unexpected environment value"); return "/lib/ld-linux-mipsn8.so.1"; } if (ToolChain.getArch() == llvm::Triple::mips || ToolChain.getArch() == llvm::Triple::mipsel) return "/lib/ld.so.1"; if (mips::hasMipsAbiArg(Args, "n32")) return "/lib32/ld.so.1"; return "/lib64/ld.so.1"; } |
lib/Driver/ToolChains.cpp | ||
---|---|---|
1943 | The downside to that is that a NDEBUG build would silently act as if the user had specified gnu regardless of what the user specified (except for the android case which is caught by the previous if-statement on line 1928). I'm not sure if that's really a problem though since using an undefined triple is likely to result in undefined defaults. | |
lib/Driver/Tools.cpp | ||
7035 | Yes, any toolchain with a NaN2008 multilib will use ld-linux-mipsn8.so.1 when given -mnan=2008. mips-mti-linux-gnu is one example but I think there are others. |
lib/Driver/ToolChains.cpp | ||
---|---|---|
1361 | Why is mti missing from this list. Either there should be both mti and img or neither | |
lib/Driver/Tools.cpp | ||
7037 | can't R6 just imply isNan2008 is true and therefore just use the logic below? | |
7043 | This looks like a bug somewhere. The layout should be the same as the existing code. Perhaps the GNU toolchain for 'img' is wrong. |
lib/Driver/ToolChains.cpp | ||
---|---|---|
1361 | I don't know why mti is missing. I haven't added it because this patch only aims to add support for the img triple. | |
lib/Driver/Tools.cpp | ||
7037 | No because the mips64r6 multilibs will try to use /lib64/ld-linux-mipsn8.so.1 when it's actually in /lib. Although, as you suggest below, it could be that the GNU toolchain is wrong. | |
7043 | It's possible that the GNU toolchain is wrong. Here are all the ld-linux-mipsn8.so.1's in the toolchain I have: $ find -name ld-linux-mipsn8.so.1 ./sysroot/el/usr/lib/ld-linux-mipsn8.so.1 ./sysroot/usr/lib/ld-linux-mipsn8.so.1 ./sysroot/mips64r6/el/usr/lib/ld-linux-mipsn8.so.1 ./sysroot/mips64r6/64/el/usr/lib/ld-linux-mipsn8.so.1 ./sysroot/mips64r6/64/usr/lib/ld-linux-mipsn8.so.1 ./sysroot/mips64r6/usr/lib/ld-linux-mipsn8.so.1 |
lib/Driver/Tools.cpp | ||
---|---|---|
7043 | Yes but I believe that is true of mti as well. I need to check but it will be tomorrow now. The paths used for the dynamic linker are those which would exist on a target filesystem and I think they are different from the paths used in the toolchain. |
lib/Driver/Tools.cpp | ||
---|---|---|
7043 | As we discussed off-review, it seems you are correct. The sysroot layout and the expected filesystem layout on the target differ so we have to account for the difference in qemu instead. |
We do not need so many files under the test/Driver/Inputs/mips_img_tree directory. Let's keep the following list because other files are not used by the test case.
- crt1.o
- crti.o
- crtbegin.o
- crtend.o
- crtn.o
Further reduced the number of files in the dummy toolchain.
Corrected ld-linux-mipsn8.so.1 path
Made mips32r6/mips64r6 the default for mips-img-linux-gnu and mips64-img-linux-gnu.
A couple more redundant file/folders:
- test/Driver/Inputs/mips_img_tree/include/dejagnu.h
- test/Driver/Inputs/mips_img_tree/sysroot/usr/lib/audit
lib/Driver/Tools.cpp | ||
---|---|---|
943 | Suppose the driver gets the following command line options: clang -target mips-img-linux-gnu -mabi=o32 -c main.c In that case the CPU name becomes mips32r2. Is that expected? I think we need to configure default CPU names in the lines 916-917. |
Removed redundant files/folders
Fixed bug Simon spotted
lib/Driver/Tools.cpp | ||
---|---|---|
943 | No, it's not expected. I've fixed this in the latest version |
Why is mti missing from this list. Either there should be both mti and img or neither