[lld] r217112 - If lld binary is named 'ld' on darwin, use darwin driver mode
Nick Kledzik
kledzik at apple.com
Fri Sep 5 18:41:26 PDT 2014
On Sep 5, 2014, at 2:49 PM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote:
> On Fri, Sep 05, 2014 at 02:40:04PM -0700, Nick Kledzik wrote:
>>
>> On Sep 5, 2014, at 2:22 PM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote:
>>
>>> On Thu, Sep 04, 2014 at 11:17:46AM -0700, Nick Kledzik wrote:
>>>>
>>>> On Sep 4, 2014, at 2:00 AM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote:
>>>>
>>>>> On Thu, Sep 04, 2014 at 12:03:37AM -0000, Nick Kledzik wrote:
>>>>>> Author: kledzik
>>>>>> Date: Wed Sep 3 19:03:36 2014
>>>>>> New Revision: 217112
>>>>>>
>>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=217112&view=rev
>>>>>> Log:
>>>>>> If lld binary is named 'ld' on darwin, use darwin driver mode
>>>>>
>>>>> I wonder if we can defer this decision until the target triple is
>>>>> actually parsed?
>>>>
>>>> What target triple are you thinking of? For the darwin linker, there is no target triple on the command line.
>>>
>>> The parsing here is for something like "target-ld", so behavior of ld
>>> can/should depend on <target>.
>> It does. The case be handled here is when the linker binary is named just “ld” and there is no -flavor option. Previously it always acted like the gnu linker. Now it acts like the darwin linker when running on darwin, otherwise like the gnu linker.
>
> I don't think it does that. parseProgramName gets called for the full
> name in case of triple prefixing. Your change breaks using e.g.
> x86_86-netbsd-ld as binary name, doesn't it?
It would only be a problem if you built the lld binary on MacOSX, renamed it to "x86_86-netbsd-ld” than ran it and expected it to behave as a gnu linker.
If you think that is a valid configuration, I can move the #if __APPLE_ check out of strToFlavor(), and instead inside UniversalDriver::link() do a check if argv[0] is exactly “ld” inside #if __APPLE_ .
-Nick
More information about the llvm-commits
mailing list