PEI 16bit relocation problem -- possible fix idea

[Mumit Khan <khan at NanoTech dot Wisc dot EDU>]

I believe there've already been bug reports on the issue that pei-coff
doesn't allow relocations larger than what fits in a 16 bit field
reserved for the relocation count. Turns out that PEI has a workaround
for this particular problem, and quoting the MSDN docs Sec 4.1 "Section 
Flags" (http://msdn.microsoft.com/library/specs/pecoff_section4_1.htm):

   IMAGE_SCN_LNK_NRELOC_OVFL indicates that the count of relocations for
   the section exceeds the 16 bits reserved for it in section header. If
   the bit is set and the NumberOfRelocations field in the section header
   is 0xffff, the actual relocation count is stored in the 32-bit
   VirtualAddress field of the first relocation.

This looks like something reasonably simple to implement given that 
RS6k/COFF (XCOFF?) has something similar. However, given my lack of BFD 
backend knowledge, I'd really like some input on how to proceed with 
this. I see the comment about "grossly abusing" coff_set_alignment_hook 
in bfd/coffcode.h, and it does smell like a hack. Is this the way to go?

Eiffel folks have been asking for this for a while now, and I guess they
will keep on using lcc-win32 as the backend for now until this is
resolved. I also have bug reports from folks who're trying to compile
machine generated code, and running into the same limitation with GNU
toolchain.

Regards,
Mumit