[patch, darwin-legacy] suppressing OS version asm directive

[Iain Sandoe]

Hi David,

The problem here is _not_ "what does the target support"?
 - but rather "what does the host toolset support"?

===

If the host toolset supports the version load-command, then the target OS version is irrelevant (there are other barriers to building for earlier systems, but that's a different story).

So, in fact, the show-stopper is not "as" (since, as Jim pointed out on irc, cctools-as doesn't support .cfi_xxx etc. which are now mandatory) - we have -integrated-as.

==

Right now, the show-stopper on cctools-795 (Darwin10, last 'official' release of XCode [3.2.6]) and cctools-689 (Darwin9, last official XCode [3.1.4]) is the other utilities like "ar" and "ranlib/libtool" which don't understand the os-version load commands.

So self-hosted will not work on Darwin <= 10 (I've not tried Darwin11, yet)
Moreover, objects built on a system that _does_ support the version load commands will be incompatible (as .o or convenience libs) on Darwin <= 10 using the xcode toolset.

I guess it also represents another barrier for foreign hosts (e.g. linux) targeting darwin.

-----

I am going to assume that this ^ situation is acceptable to everyone except the legacy Darwin Users ;)

Of course, one could wrap the relevant code in an ifdef based on the build system - on the assumption that build == host in the usual case...
.. but I doubt that will be a popular proposal. 

-----

So .. proposed solution:

1. I am close (very) to announcing a back-port of cctools-845*** + ld64-127.2 that will allow:
  (a) Darwin >= 11 to build for earlier systems
  (b) Darwin <= 10 to self-host with the more modern facilities.

 - this supports the version load commands in the other toolchain components (of course, one needs to ensure that they are not placed into final executables, because the earlier Darwin's dyld doesn't grok them either).
 - hopefully, I'll be able to make this toolset buildable on Linux too .. 

2. I am not quite so close, (but fairly) to announcing a Mach-O GAS port supporting ppc and x86 that, of course, does deal with .cfi_xxx.  I can add the .macosx_version directive to that (if it becomes relevant).

3. Perhaps llvm-* can be used in some capacity (or updated if not).

4. dsymutil remains a (very) thorny issue.

----

[[aside:  In fact, this really (once again) highlights that we don't have a good consistent mechanism for identifying and passing the relevant capabilities around; it should be possible to disable the facility on hosts that don't support it -- hopefully part of what gets discussed at the toolchain bof in Edinburgh]]

cheers
Iain

*** it would be very nice to see the XCode 5 OS stuff released soon .. hint, hint :)

On 4 Apr 2014, at 01:00, David Fang wrote:

> Hi Jim,
> 	But won't i386/x86_64-apple-darwin10 have the same problem? with its gcc-4.2-based toolchain?  I guess it all boils down to detecting (or assuming based on OS) characteristics of the cctools being used.  (I use -B to point to cctools that live outside the system compiler toolchain, for example.)  Iain, did you say you also observed this break on darwin11 too?
> 
> David
> 
>> Hi David,
>> 
>> I think we?re going to have to be a little more clever here. The intent of these directives is to enable better build time diagnostics when mixing and matching deployment targets that are older than the tools being used. Perhaps we could disable if the target is ppc*-apple-darwin instead?
>> 
>> -Jim
>> 
>> On Mar 27, 2014, at 4:56 PM, David Fang <fang at csl.cornell.edu> wrote:
>> 
>>> Hi Jim,
>>> 	A few weeks ago, you alerted us darwin-legacy users that r204190
>>> 	and r204191 added a new asm directive that would break
>>> 	compatibility with older cctools.  My regression testing found
>>> 	that test/CodeGen/PowerPC/hello-reloc.ll had failed due to
>>> 	different macho-dump, for instance. I took a stab at the attached
>>> 	patch to suppress this new directive (guessing that OS X 10.9 is
>>> 	the cut-off).  The patch restores my regression tests to their
>>> 	previous state.  Does this seem like an adequate workaround for
>>> 	legacy support?
>>> 
>>> David
>>> 
>>> --
>>> David Fang
>>> http://www.csl.cornell.edu/~fang/
>>> <llvm-suppress-osversion-asm-directive.patch>
>> 
> 
> -- 
> David Fang
> http://www.csl.cornell.edu/~fang/
>