[cfe-dev] Program path lookup for MIPS targets

[Chandler Carruth]

On Thu, Mar 15, 2012 at 11:02 PM, Simon Atanasyan <satanasyan at mips.com>wrote:

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120315/5ccb82ec/attachment.html>