Program path lookup for MIPS targets

Hi,

I want to fix a bug/issue in clang driver which can be described by
the following user story:
1. User wants to create a program for MIPS little-endian target.
2. User downloads and installs MIPS toolchain (say from CodeSourcery).
This toolchain provides mips-linux-gnu-ld tool. This linker generates
code for both big and little endian targets.
3. User runs "clang –target mipsel-linux-gnu –sysroot=..." but
linking fails because clang cannot find "mipsel-linux-gnu-ld" and
attempts to use "ld".

In fact clang driver passes correct command line options to the
linker. If the user creates a symbolic link mipsel-linux-gnu-ld to
mips-linux-gnu-ld, clang produces code for little-endian target. It's
a workaround but I'd like to avoid it.

The problem seems to be in the Driver::GetProgramPath() routine. If we
request a path to "ld" for mipsel-linux-gnu target, this function
searches either DefaultTargetTriple+"ld" ("mipsel-linux-gnu-ld" in our
case) or "ld" and does not search "mips-linux-gnu-ld".

I’d like to get an advice how to fix this issue. Maybe I just do not
know about appropriate command line options. Put the knowledge of MIPS
targets to the Driver::GetProgramPath() is a straightforward solution
but looks ugly.

Thanks.

Hi,

I want to fix a bug/issue in clang driver which can be described by
the following user story:

  1. User wants to create a program for MIPS little-endian target.
  2. User downloads and installs MIPS toolchain (say from CodeSourcery).
    This toolchain provides mips-linux-gnu-ld tool. This linker generates
    code for both big and little endian targets.
  3. User runs “clang –target mipsel-linux-gnu –sysroot=…” but
    linking fails because clang cannot find “mipsel-linux-gnu-ld” and
    attempts to use “ld”.

In fact clang driver passes correct command line options to the
linker. If the user creates a symbolic link mipsel-linux-gnu-ld to
mips-linux-gnu-ld, clang produces code for little-endian target. It’s
a workaround but I’d like to avoid it.

The problem seems to be in the Driver::GetProgramPath() routine. If we
request a path to “ld” for mipsel-linux-gnu target, this function
searches either DefaultTargetTriple+“ld” (“mipsel-linux-gnu-ld” in our
case) or “ld” and does not search “mips-linux-gnu-ld”.

I have a partial solution implemented. As soon as I clean off some high priority optimization work I’ve got on my plate, I’ll return to this.

If you’d like, I can send you what I have so far, but it’s not in terribly good state yet. Among many other issues, fixing this requires us to change how we are using the triples being passed around so that they are in perfect shape for use when searching program path.

I’d like to get an advice how to fix this issue. Maybe I just do not
know about appropriate command line options. Put the knowledge of MIPS
targets to the Driver::GetProgramPath() is a straightforward solution
but looks ugly.

Agreed. There is an (imo) equally ugly hack in the NetBSD toolchain. You could do either one in the short term if this is blocking folks.

My only request is that if you go this route you provide some good test cases and plenty of FIXMEs so we know what code to delete when we have a proper solution, and we don’t regress accidentally.

Yes, I'd like to get the code. At least I will be able to estimate a
complexity of the problem.