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

login
register
mail settings
Submitter Jack Howarth
Date Oct. 2, 2010, 8:20 p.m.
Message ID <20101002202018.GA16460@bromo.med.uc.edu>
Download mbox | patch
Permalink /patch/66580/
State New
Headers show

Comments

Jack Howarth - Oct. 2, 2010, 8:20 p.m.
On Sat, Oct 02, 2010 at 08:36:16PM +0100, Dave Korn wrote:
> On 02/10/2010 18:14, Ralf Wildenhues wrote:
> > * Dave Korn wrote on Sat, Oct 02, 2010 at 07:05:02PM CEST:
> >> On 02/10/2010 17:13, Jack Howarth wrote:
> >>> On Sat, Oct 02, 2010 at 06:00:36PM +0200, Ralf Wildenhues wrote:
> 
>   Ralf, Jack: your arguments are persuasive.  How about if I re-do the
> configury so that a) LTO is enabled for windows by default, as it is for
> darwin, and b) the lto-plugin is enabled on (both) those platforms?

Dave,
   Part (a) should just require the change...


Regarding part (b), I am unclear if this lto-plugin will require the use
of binuils on darwin. 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.
            Jack

> 
>   (I'll add the Mach-O stub files to the plugin while I'm at it.)
> 
>     cheers,
>       DaveK
Dave Korn - Oct. 2, 2010, 9:17 p.m.
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!

> 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?

    cheers,
      DaveK
Jack Howarth - Oct. 2, 2010, 9:59 p.m.
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!
> 
> > 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.
                 Jack

> 
>     cheers,
>       DaveK
IainS - Oct. 2, 2010, 10:55 p.m.
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
Dave Korn - Oct. 3, 2010, 1:05 a.m.
On 02/10/2010 23:55, IainS wrote:
> On 2 Oct 2010, at 22:59, Jack Howarth wrote:

>> Dave,
>>   I would lean towards tethering it --with-gnu-ld. 

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

  Well, that's the deal-breaker right there, I'm pretty sure.

> 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 ;)

  Although it wouldn't kill anyone to build a dummy library that gets
installed and never used, I'll tie it to gnu ld on darwin.

    cheers,
      DaveK
Dave Korn - Oct. 3, 2010, 1:06 a.m.
On 03/10/2010 02:05, Dave Korn wrote:

>> However, there is only partial support for mach-o/darwin in gas, and
>> none (AFAIK) in ld.
> 
>   Well, that's the deal-breaker right there, I'm pretty sure.

>   Although it wouldn't kill anyone to build a dummy library that gets
> installed and never used, I'll tie it to gnu ld on darwin.

  Sorry, thinko.  I mean "disable it altogether" on darwin.  No point if
neither cctools nor binutils support it.

    cheers,
      DaveK

Patch

Index: configure.ac
===================================================================
--- configure.ac	(revision 164904)
+++ configure.ac	(working copy)
@@ -1788,7 +1788,7 @@ 
   AC_SUBST(libelfinc)
 fi],[if test x"$default_enable_lto" = x"yes" ; then
     case $target in
-      *-apple-darwin*) ;;
+      *-cygwin*|*-mingw* | *-apple-darwin*) ;;
       # On other non-ELF platforms, LTO must be explicitly enabled.
       *) enable_lto=no ;;
     esac