[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