Re: [PATCH] Implement lto-plugin for COFF on windows.

[Dave Korn <dave dot korn dot cygwin at gmail dot com>]

On 18/10/2010 00:08, Joseph S. Myers wrote:
> On Sun, 17 Oct 2010, Dave Korn wrote:
> 
>> +case $target in
>> +  x86_64*-mingw*)
>> +    SYM_STYLE=-DSYM_STYLE=ss_none
>> +    LTO_FORMAT=coff
>> +    COFFENDIAN=-DCOFFENDIAN=0
>> +    ;;
>> +  *-cygwin* | i?86*-mingw* )
>> +    SYM_STYLE=-DSYM_STYLE=ss_win32
>> +    LTO_FORMAT=coff
>> +    COFFENDIAN=-DCOFFENDIAN=0
>> +    ;;
> 
> The different SYM_STYLE settings determined at compile time look odd.  If 
> x86_64-mingw32 doesn't support multilib configurations with both 32-bit 
> and 64-bit multilibs, they would certainly be a natural extension, and it 
> would be natural to expect them to be compatible with i686-mingw32 
> (meaning that SYM_STYLE must depend on the multilib in use) - is that not 
> the case?

  Hmm, sounds right.  How about if I make SYM_STYLE the default and provide a
-plugin-opt to allow it to be switched at runtime if desired (which could be
controlled by a spec in the backend)?

> @option{-pass-through}, if this is the name of an option to something.

> @option{-l}

  Thanks.

>> +#ifndef COFF_HELP_H
>> +#define COFF_HELP_H
>> +
>> +/* Rather than implementing a libcoff to match libelf, or attempting to
>> +   integrate libbfd into GCC, this file is part of a self-contained (and
> 
> Or using the include/coff files in the src repository and sharing whatever 
> is needed with GCC?  I suppose those files are too closely tied to BFD to 
> be usefully usable in GCC as headers to describe the COFF format?

  The various bits and pieces are scattered across a whole bunch of the bfd
headers, it would have been a whole bunch of extra sharing just for the sake
of four structs and a handful of #defines.  It's not really meant to be a
public API; would it maybe be better to put it in gcc/ and #include it via a
"../gcc/...." relative path from the plugin (or by adjusting -I options in the
makefile appropriately)?

    cheers,
      DaveK