similar to: RFC: A new llvm-dlltool driver and llvm-lib driver improvements

Hey Rui, > 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? Other then changing `lib/MC/WinCOFFStreamer.cpp` to not use -aligncomm within the EmitCommonSymbol function and a single patch for mingw-w64 itself to

> > Also you need to make a change to LLD/COFF to accept GNU command > arguments, right? (Looks like you already have that patch locally.) Yes > My patch to hack lld into accepting some very basic gnu front end > arguments was enough to get all the above working which was enough to > develop further. On Mon, Feb 13, 2017 at 8:41 PM, Rui Ueyama <ruiu at google.com>

> > I wonder if it can be a wrapper for LLD/COFF. It can be an in-process > wrapper, meaning that you could add a main function for mingw which > translates all arguments into the MSVC style and then invoke the COFF > linker's main function. That should work, if I am understanding this correctly I can create an argument parser (probably partially based on the ELF one) then I

> > No, I meant an even thinner wrapper which textually translates arguments. > For example, the wrapper would translates "/out:foo.exe foo.obj" to "-o > foo.exe foo.obj" and then call lld::COFFF:link(). It doesn't do anything > with Config object nor LinkerDriver::run and have absolutely zero knowledge > on the internals of LLD. Ohh okay I misunderstood.

On Mon, Feb 13, 2017 at 5:20 PM, Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Mon, Feb 13, 2017 at 4:46 PM, Martell Malone <martellmalone at gmail.com> > wrote: > >> No, I meant an even thinner wrapper which textually translates arguments. >>> For example, the wrapper would translates "/out:foo.exe foo.obj" to "-o

Ohh nice. With that method I can support it without upsetting ld users by introducing an api breakage. On Tue 14 Feb 2017 at 01:32, Rui Ueyama <ruiu at google.com> wrote: > On Mon, Feb 13, 2017 at 5:26 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > > On Mon, Feb 13, 2017 at 5:20 PM, Rui Ueyama via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >

Yes, that would be the long term plan. llvm-link ideally would share the same library. I'm not sure where it should live though. On Tue 14 Feb 2017 at 01:49, Rui Ueyama <ruiu at google.com> wrote: > I took a look at the code. Looks like you need a library to create import > library files in LLVM and use that from llvm-dlltool and LLD. Is that what > you are planning? > >

Well that means it would just be the only plan then. I assume the first step would be to move the code from lld into this new library and lld can use that? I can then re add the extra functionality for weak externals? We can then have lib and dlltool use this then. On Tue 14 Feb 2017 at 01:58, Rui Ueyama <ruiu at google.com> wrote: > On Mon, Feb 13, 2017 at 5:56 PM, Martell Malone

Hi again rui, :) I've got all the patches into llvm and clang for supporting mingw-w64 via compiler-rt and now we are able to build a full mingw-w64 toolchain without gcc :) With great help from yaron and rnk. I've CC'd them as they might have interest in seeing this target through with me to the end :) So I have again turned my attention to LLD so that we can also remove ld as a

After some more digging and creating a few testcases in lld I have narrowed it down to The fact that dlltool generates Contents of section .idata$7: 0000 55534552 33322e64 6c6c0000 USER32.dll.. Where as lld expects Contents of section .idata$6: 0000 55534552 33322e64 6c6c0000 USER32.dll.. I recreated the hello64.test using dlltool for the lib and here is the asm dump of

I forgot to attach the notes.txt with the objdump. On Thu, Jul 23, 2015 at 3:55 PM, Martell Malone <martellmalone at gmail.com> wrote: > Hi again rui, :) > > I've got all the patches into llvm and clang for supporting mingw-w64 via > compiler-rt and now we are able to build a full mingw-w64 toolchain without > gcc :) > With great help from yaron and rnk. > >

Hey guys, So I was able to modify dlltool to produce the exact same layout as lib.exe with the same section numbers etc. I've first managed to first create the correct section so that lld gives me link errors and then resolve those errors to create an exe. This is one thing that is still missing that sticks out like a sore thumb In the actual imports of the functions the objects are very

On Sat, Jul 25, 2015 at 5:24 PM, Martell Malone <martellmalone at gmail.com> wrote: > It's doable to support dlltool-style import libraries by LLD. .idata >> sections in dlltool-style libraries are designed so that they will >> naturally construct the import descriptor table by just sorting them by >> section name. Supporting them is not hard. > > > I

> > It's doable to support dlltool-style import libraries by LLD. .idata > sections in dlltool-style libraries are designed so that they will > naturally construct the import descriptor table by just sorting them by > section name. Supporting them is not hard. I don't really know my way around the code base of COFF well enough todo this myself. If you can point me in the

Hi Rui, Thanks for getting back to me on this Do you think that you can make dlltool to generate short import libraries? > If you can, it would be the easiest way to solve the issue. > On my current tests ld seems to not like libraries built with short import libraries so this would require an ABI break in binutils. dlltool has support for loads of legacy targets and changing this would

It's doable to support dlltool-style import libraries by LLD. .idata sections in dlltool-style libraries are designed so that they will naturally construct the import descriptor table by just sorting them by section name. Supporting them is not hard. One thing we need to do is that currently we construct the import descriptor directly from short import libraries. We don't create

Hi Martell, Sorry for the belated response. I missed this email. I took a quick look at the library file you have attached and noticed that the file consists of regular object files. LLD expects that all dllimported symbols are described using "short import library" (PE/COFF spec 7). Because I didn't test LLD with dlltool-style archive files, it's no surprise that it didn't

> > For example the gnu linker provides the section with the stub code and the > offset for injection. Meant to say dlltool here not gnu linker :) On Sat, Jul 25, 2015 at 11:17 AM, Martell Malone <martellmalone at gmail.com> wrote: > Hey guys, > > So I was able to modify dlltool to produce the exact same layout as > lib.exe with the same section numbers etc. >

Hi Ivan, :) For testing purposes, I've managed to make the old COFF linker work with a > simple test case > Have you got patches for this that I can look at ? Had to make two little changes, and link the exe manually, because the > linker doesn't understand the GNU flags > I've solved the issue of having a GNU driver for the linker so that's not an issue anymore I

Hi Rui, I have finished my tool to generate short import libs for mingw-w64. It works fine with lld for actual symbols. But it seems lld segfaults when I try to use and an alias as we discussed before. I have attached 3 import libraries. They all only have 1 import function. libuser32orig.a -> Works fine and only has MessageBoxA libuser32b.a -> the symbol table has MessageBoxB and