[llvm-dev] RFC: A new llvm-dlltool driver and llvm-lib driver improvements

[Rui Ueyama via llvm-dev]

Hi Martell,

I wonder how llvm-dlltool would fit in the entire picture of mingw support.
I don't think dlltool is the last missing piece. What do you need to do
other than that to fully support mingw using LLVM toolchain?

On Mon, Feb 13, 2017 at 8:56 AM, Martell Malone via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hey llvm'ers,
>
> I have been working on a dlltool replacement for llvm.
> Here is my initial differential https://reviews.llvm.org/D29892
> It is based on some functionality that already exists in lld.
> I added functionality to support, PE COFF Weak Externals and of course a
> front end to actually use it.
> I believe the work here can also be used for llvm-lib and lessen the load
> on lld.
> I would like some comments about how this could be be structured to live
> in llvm with a shared code base across lib ar and dlltool.
> I also have a section below called "Difference from lib" which is somewhat
> of a rationale for the tool.
>
> Many Thanks,
> Martell
>
>
> Context
> ==========
>
> Awhile back I talked to various llvm'ers about getting mingw-w64 support
> for lld.
> There were a few issues raised but the main issue was that mingw-w64
> should try best to comply with the PECOFF spec, adding support for custom
> sections and various binutils/mingw hacks would impact the performance of
> the COFF linker and in general is not something that lld should support.
>

It's not a performance issue but a code maintenance issue. The initial
patches to support mingw was trying to add a new linker driver and a
different linkin semantics to the COFF linker which seemed too complicated
to me. IIRC, I suggested adding a shim which translates GNU command line
arguments to MSVC linker arguments. Didn't it work?


> Motivation
> ==========
>
> The main motivation was because dlltool and ld did not comply with PECOFF
> Spec.
> It has some custom formatting and uses the assembler for some reason to
> generate import libraries, it did not use the short import library format
> at all.
>
> There has been many work arounds for the problem this creates such as the
> creation of the `reimp` tool. Which imports MSVC built libs creates a def
> and uses dlltool so that the binutils linker can use it.
>
> We should just be using the short import format and the linker should
> support that.
> Thus llvm-dlltool was born.
>
>
> Difference from lib
> ===================
>
> Using PE COFF spec (section 8, Import Library Format) should be self
> explanatory.
> lib.exe is able to accept def files and create libraries using this format.
>
> example
>
>   `LIBRARY "user32.dll"
>    EXPORTS
>    MessageBoxA`
>
> LIB.exe can create a user32.lib with the function MessageBoxA from the
> above definition.
>
> Mingw-w64 is different MSVC in that we need to compile the runtime.
> MS provide us with their crt prebuilt so lib.exe doesn't have support for
> external function aliasing.
> We often use aliases for posix naming reasons as well as avoid using the
> MS version of a function.
>
> example
>
>   `LIBRARY "user32.dll"
>    EXPORTS
>    MessageBoxA
>    MessageBoxW==MessageBoxA`
>
> LIB.exe doesn't not have support for this but dlltool does.
> The best fit for this within the spec is PE COFF spec (Aux Format 3: Weak
> Externals)
>
> Mingw-w64 also uses lib prefix and .a file extensions for the library name
> so the driver should be different. The above example would be libuser32.a,
> for when shared and static versions of the same library exist there is the
> .dll.a variant.
>
>
> Issues
> =======
>
> Like more of the gnu suite dlltool was not designed in one build multi
> target manner.
> We would have to introduce custom arguments to specify the target, "i686",
> "x86_64", "thumb2pe" etc.
> This will most likely break some level of backwards compatibility with the
> binutils version.
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170213/6c149eb5/attachment.html>