[PATCH] LTO plugin for coff, part 1: break out ELF-specific code and enable COFF builds

[IainS]

On 2 Oct 2010, at 22:59, Jack Howarth wrote:

> On Sat, Oct 02, 2010 at 10:17:14PM +0100, Dave Korn wrote:
>> On 02/10/2010 21:20, Jack Howarth wrote:
>>
>>> Regarding part (b), I am unclear if this lto-plugin will require  
>>> the use
>>> of binuils on darwin.
>>
>>  Well, yes, unless you can add it to cctools!

it's worth a look - it's likely to be a lot closer target than binutils.

>>> If so, it will definitely be a niche change for darwin
>>> as the vast majority of users will want to build with FSF gcc  
>>> using the standard
>>> darwin cctools from Xcode. IMHO, binutils is not likely to be well  
>>> supported on
>>> darwin for use beyond cross-platform builds of the darwin target.  
>>> I definitely
>>> would not want to see lto require binutils for standard usage.
>>
>>  OK, but bear in mind that whether we build/install it is separate  
>> from
>> whether we actually invoke it at runtime in the installed compiler,  
>> which is
>> controlled by whether we have -fuse-linker-plugin or not.  I  
>> haven't yet
>> figured out where exactly -fuse-linker-plugin comes from yet, but  
>> in general
>> top-level configure can only decide what to build or not, while gcc/
>> subconfigure is responsible for knowing the details of how to  
>> invoke target
>> native tools at runtime.  So would you be OK with it getting built  
>> but unused,
>> or would you like me to make it depend (in the darwin case only) on  
>> being
>> configured --with-gnu-ld?
>
> Dave,
>   I would lean towards tethering it --with-gnu-ld. Iain should be  
> able to test
> this option since he appears to do regular builds against binutils  
> for the darwin
> targets.


As of now, bfd supports mach-o pretty well - (and therefore tools like  
objdump are functional).

However, there is only partial support for mach-o/darwin in gas, and  
none (AFAIK) in ld.

So, if we are to make use of this facility (in the near term)  it will  
have to be in conjunction with darwin's own ld or a cctools merge.
(and I have no idea what the magnitude of the integration task is  
there).

Therefore, right now,  we should stick with ensuring that the build  
machinery works (and anchor that to something safe, that won't scupper  
ordinary users) ..
Then someone can work on filling in the gaps when we have some dev  
effort spare ;)

also  I have in mind (prob in 4.7 now) investigating splitting  
machopic out of darwin.c & config/{rs6000,i386} so that we can create  
darwin objects in other containers (read elf)...
... although the motivations for this stem from removing conditionals  
in the target sources ...
... that might open up some other opportunities...

(Mike's suggestion to dispense with the asm between the compiler &  
collect is probably a neater solution all round).

thanks for doing this Dave,

Iain