Library search paths on biarch systems

Hi,

I noticed that the Linux toolchain also adds the default multilib to the search path when targeting the "other" multilib that the biarch gcc installation supports. For example, in a gcc installation providing two multilibs: '.;@m32' and '64;@m64', when -m64 is specified on the clang command line, both <gcc>/<triple>/<ver>/64/ and <gcc>/<triple>/<ver>/ are added to the search paths (There's a couple of tests for this specific case in clang/test/Driver/linux-ld.c:109 and clang/test/Driver/cross-linux.c:57).

Is this correct for the opposite case (i.e. gcc providing '.;@m64' and '32;@m32' with -m32 on the command line) for which there don't seem to be any tests for or against it? How about on PPC64?

Jon

A long time ago, I built GCC installs and created as many directories as I
could (even if empty) to try to test all of the search paths that it ended
up using. It *appeared* at the time that this was intentional, and it made
everything more complex to be asymmetrical here. I would rather keep the
symmetry to simplify the code and logic unless doing so breaks something
really horrible.

Similarly, I'm hoping desperately that we can have the same biarch search
pattern for PPC, x86, mips, and whatever other biarch toolchains we end up
with. I don't want to start having different logic for each cpu type...

The main reason I'm asking is because I'm trying to unify the BiarchSuffix stuff with the multilib part of MIPSABIDirSuffix so I can add support for multilibs in the more general case. Logically, MIPSABIDirSuffix seems to be doing two things: in some places it acts like a multilib directory suffix to the gcc installation, and other times it acts like a suffix to the os lib directory (i.e. MULTILIB_DIRNAMES vs MULTILIB_OSDIRNAMES in gcc configs).

That particular case makes it awkward because the default multilib on the mips toolchains isn't always appropriate, meaning there needs to be more to it than just keeping symmetry... so I think cpu-specific code here is unavoidable (and it almost certainly was anyway considering the multilib selection problem that comes with this project).