Hi all,
the last issue I have with using $TARGET-clang and associated
$TARGET-ld/$TARGET-as handling for the NetBSD cross-compiling setup is
the interaction with -m32. The current logic modifies the target when
-m32 is found and ends up calling different as/ld instances as a result.
One problem is that at least for NetBSD, the GNU style triple for i386
and x86_64 are different, since i386-netbsd is actually the legacy a.out
target.
The attached part distinguishes between the triple given by the user and
whatever is passed down to different parts of clang (cc1, clang-as).
It does the job, but this is going to duplicate a lot of code for other
platforms. The other issue of course is the XXX comment at the end about
toolchain caching. This would work at the moment, since the primary
triple is the same for all compilations inside clang, but would fail as
soon as a clang daemon was written.
Joerg
tool-prefix.diff (6.25 KB)
If I'm understanding correctly, passing -m32 to clang targeting
x86_64--netbsd is supposed to make executables targeting
i486--netbsdelf, but is incorrectly trying to use tools for
i486--netbsd. You're trying to fix this by keeping around the
original target triple, and pretending that a i486--netbsd triple is
actually i486--netbsdelf if the original triple is x86_64--netbsd. It
seems like it would be much more straightforward to just fix the
triple-handling code so that passing in -m32 figures out the correct
triple.
-Eli
Not exactly. Passing -m32 should have two results: *compile* for the
equivalent of i386--netbsdelf and call as/ld with the correct 32bit
flags. My problem here is that the original triple is "lost", so it
tries to call the wrong cross-compile as/ld and uses the wrong arguments
for those. E.g. correct behavior is to either call a x86_64 as with --32
or a i386 as without, but currently neither happens.
The patch contains this in the NetBSD specific targets, but I believe
that the problem of distinguishing -m32 from "native" 32bit compilation
might be a bit more popular to duplicate all the code.
Joerg
I can see why the distinction is useful.
Given that you're only touching the NetBSD-specific code, whatever you
think is appropriate is probably close enough. You might be taking a
substantial perf hit from eliminating the cache, though.
-Eli