[patch] Don't produce stubs on darwin x86
Iain Sandoe
iain at codesourcery.com
Wed Dec 4 06:37:18 PST 2013
On 4 Dec 2013, at 14:07, Rafael EspĂndola wrote:
>> So the questions are
>> do we want to be able to:
>> (a) self-host on earlier versions of OSX? (i.e. darwin8)
>> (b) build objects that can be linked by the native toolset on darwin8?
>>
>> if either answer is "yes" then the stubs creation code would still be needed.
>>
>> Also, really, the linker version should be passed through to the target - it's the best way of making the correct decision here. Not sure whether it would be best to parse it into a version number (which is easier to test) or just leave it as a string (which is more flexible).
>
> I agree with the statement.
Apropos the linker version, I would like to see this being available to support differences between native sets on OSX10.{6,7+} as well as earlier - so it would be good to decide on a way to push this through [and add it as a c/l option to llc].
Is it on someone's TODO - or should I propose a patch?
> I am not sure what the answer is regarding
> darwin8. This patch is basically an alternative to
>
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131125/197042.html
>
> We should fix the stub creation or remove it :-)
Ah yes, non-working stubs make no sense :)
===
Personally, I cheered when the need for stubs was removed - they make asm pretty unreadable, however, it's not my call - although I do still have some darwin8 systems in regular use.
* pro removal - makes support easier.
* con removal - it means that someone can't "just build" llvm/clang on darwin8 - they would need to build a supplementary toolset including ld >= 85.2.1 [although there are solutions out there for this].
Iain
More information about the llvm-commits
mailing list