search for: dlltool

> > 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 we...

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 llv...

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 d...

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 don't really know my way around...

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 changin...

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 the final...

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 fu...

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 th...

...ove working which was enough to > develop further. On Mon, Feb 13, 2017 at 8:41 PM, Rui Ueyama <ruiu at google.com> wrote: > On Mon, Feb 13, 2017 at 12:33 PM, Martell Malone <martellmalone at gmail.com> > wrote: > >> 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 -alignco...

...d for this target Previously I raised the issue that while lld would infact link exe's for me the issue was the sections were malformed and thus crashed on launch. I've done some debugging reguarding this and discovered it is due to differences between what MSVC's lib.exe and binutils dlltool produces I have attached a very simple .def file and generated libs via dlltool along with an objdump -s log of the lib.exe version I don't know too much about the internals of lld to be able to tell the exact cause of the problem but there are 3 specific differences I noted. 1. With dlltool...

...rstanding this correctly I can create an argument parser (probably partially based on the ELF one) then I can set the data in the COFF Config object and call COFF LinkerDriver::run etc directly from that? This proposal is for generally moving code from lld into llvm that could be part of lib.exe / dlltool, what are your thoughts here? On Mon, Feb 13, 2017 at 8:57 PM, Rui Ueyama <ruiu at google.com> wrote: > On Mon, Feb 13, 2017 at 12:52 PM, Martell Malone <martellmalone at gmail.com> > wrote: > >> Also you need to make a change to LLD/COFF to accept GNU command >>&...

...Previously I raised the issue that while lld would infact link exe's for > me the issue was the sections were malformed and thus crashed on launch. > > I've done some debugging reguarding this and discovered it is due to > differences between what MSVC's lib.exe and binutils dlltool produces > > I have attached a very simple .def file and generated libs via dlltool > along with an objdump -s log of the lib.exe version > > I don't know too much about the internals of lld to be able to tell the > exact cause of the problem but there are 3 specific differenc...

...ngw. If all differences are > superficial, the command line translator should just work. If not, there's > some semantic difference.) The libraries can be used with MSVC link.exe directly assuming the correct arguments are passed to the linker. I tested this after creating a working llvm-dlltool. The only change I had to make to support this was alter ming-w64 crt to change all references from __image_base__ to _ImageBase to support that That should be fine. Great On Mon, Feb 13, 2017 at 9:34 PM, Rui Ueyama <ruiu at google.com> wrote: > On Mon, Feb 13, 2017 at 1:16 PM, Martell...

.... 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? > > On Mon, Feb 13, 2017 at 5:37 PM, Martell Malone <martellmalone at gmail.com> > wrote: > > Ohh nice. > With that method I can support it without upsetting ld users by > introducing an api breakage. > > On Tue 14 Feb 20...

Hi, I've been trying to get the python bridge (rpy2) to build for 64-bit R and python. The current stumbling block is that mingw can't use the python27.lib file that comes with CPython and so I need to generate libpython27.a. When I use dlltool from rtools to do that however, I end up with a 32-bit file: >"G:\Rtools\gcc-4.6.3\i686-w64-mingw32\bin\dlltool" -e libpython27.a -d python27.def python27.dll >objdump -f libpython27.a libpython27.a: file format pe-i386 More problematically, x86_64 is not listed as supported...

...nces are > superficial, the command line translator should just work. If not, there's > some semantic difference.) > > The libraries can be used with MSVC link.exe directly assuming the correct > arguments are passed to the linker. > I tested this after creating a working llvm-dlltool. > The only change I had to make to support this was alter ming-w64 crt to > change all references from __image_base__ to _ImageBase to support that > > > You may be able to define __ImageBase as a weak external symbol to > __image_base__. Then, if __ImageBase is not defined, all...

...l, the command line translator should just work. If not, there's >>> some semantic difference.) >> >> The libraries can be used with MSVC link.exe directly assuming the >> correct arguments are passed to the linker. >> I tested this after creating a working llvm-dlltool. >> The only change I had to make to support this was alter ming-w64 crt to >> change all references from __image_base__ to _ImageBase to support that >> > > You may be able to define __ImageBase as a weak external symbol to > __image_base__. Then, if __ImageBase is not d...

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 <martellmalone at gmail.com> > wrote: > > Yes, that would be the long term plan. > llvm-link ideally would share the same library. > I...

> > 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. > I've first managed to first creat...

Hello: I'm trying to use Rcmd SHLIB to compile a single file, sann.c, to get sann.dll. I was able to get make libR.a to work, after going into MkRules and changing the line DLLTOOL=$(BINPREF)dlltool -k --as $(AS) to read DLLTOOL=C:/MINGW-1.1/bin/dlltool -k --as $(AS) But now I get: C:\rw1051\src\gnuwin32>Rcmd SHLIB sann.c make: make: Command not found make: *** [libR] Error 127 My path is as follows: C:\rw1051\src\gnuwin32>path PATH="C:\Rtools\";C:\Ming...