Re: mingw DLL import library compatibility (with trivial patch)

[Kai Tietz <ktietz70 at googlemail dot com>]

Hello Doug,

2010/3/12 Doug Semler <dougsemler@gmail.com>:
> Well, I figured out the "issue," if you could call it that. ?It turns
> out that the MS linker doesn't resolve/merge RVAs in the .idata$*
> sections unless the reference is in the same COFF object, or (if the
> object is in an archive) the archive name is the same (figured this
> out by reading the PE-COFF spec very carefully :)). ?If I extract the
> archive members generated by the binutils ld, and rename them to the
> same name and add them to a .lib file, the references are resolved
> properly. ?In addition, if the (common) name of the archive member
> ends in ".dll", the binutils linker is able to use the resulting
> import library without change, because it scans the archive for .idata
> sections in *.dll archive members and renames them internally so they
> are sorted properly.

Yes, this solution sounds reasonable to me. You need to do papers with
FSF for binutils. See at
http://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html for
some more information.

> I created a patch that adds a new parameter to ld
> (--mslink-compatible-implib), which would be used in pe-dll.c to
> generate a archive member name that is the same across the board in
> import libraries. ?I'd like to submit it for comment/inclusion, but it
> is non trivial so I need to know what I need to do to get the
> copyright assignment paperwork done. ?It's the parameter addition that
> makes the patch non trivial - using the parameter is not really needed
> since the linker currently supports the VS style import libraries ---
> except that by adding the parameter, you keep the original
> functionality of unique archive member names intact. ?Adding the same
> functionality to dlltool would require a bit more work, since dlltool
> writes temporary object files and uses them directly (which means the
> method I use now of extracting, rename, and add to new library is the
> only really good method of generating the library).
>
> However, I'd like to submit this trivial patch to make the object
> files in import libraries more compatible with the current native
> toolchains. ?It makes the .text section readonly which rids a linker
> warning about text sections with different attributes and also adds
> the absolute symbol @feat.00 (value of 1) to the X86 jump table
> objects which flags the objects as /SAFESEH compatible (which they are
> since they are just jumps to an RVA in the import table).
>
> ? ? ? ?* pe-dll.c (make_one): Make text section readonly.
> ? ? ? ?(make_one): Add *ABS* symbol @feat.00 with value 1 to tag
> ? ? ? ?the jump stub on X86 as /SAFESEH compatible for
> ? ? ? ?native toolchains.

In general it would be good to put those import-library generation
routines into pe-coff specific parts of bfd. So we could avoid
different behavior of dlltool and ld. Also it would allow us to
implement the new ANON object format used by MS for import symbols
(also described in PE-COFF specification).

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination