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

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

    Hi Richard,

  I've made all the other changes you and Joseph mentioned, but I want to talk
about this one a bit:

On 18/10/2010 16:54, Richard Henderson wrote:

>> +  for (n = 0; n < num_coff_known_machines; n++)
>> +    if (*mach == coff_machine_array[n])
>> +      break;
>> +  if (n == num_coff_known_machines)
> 
> If you're going to recognize an arbitrary set of coff
> machines, why are you hard-coding ...
> 
>> +  x86_64*-mingw*)
>> +    SYM_STYLE=-DSYM_STYLE=ss_none
>> +    LTO_FORMAT=coff
>> +    COFFENDIAN=-DCOFFENDIAN=0
>> +    ;;
> 
> ... endianness?

  Well.  The check on the machine number is really just there as a basic
sanity test, COFF files not having anything else by way of a magic number to
identify them.

  None of the currently-supported targets have any kind of bi-endianness, and
while that might change in the future if someone wants LTO on a mips or rs6000
coff target (assuming there even are any), for now I couldn't see the
advantage in actually compiling the endianness helpers runtime switchable, I
thought it better to make the endianness definition a compile-time constant so
that all those ternary operators and the corresponding unused-endianness
inline get/setters can be optimised away.

  In the lto frontend, I just allow the endianness to be inferred from
BYTES_BIG_ENDIAN, but the target macros aren't available in the lto-plugin,
and rather than draw in tm.h (with all the dependencies that that implies), I
took the simplistic solution.

  Given the above, would you be OK with leaving it like that for now, and only
revisiting it /if/ anyone ever decides to add LTO support for other COFF targets?

  I'll send a revised patch once you let me know your decision on this.

    cheers,
      DaveK