similar to: git mirror of lld does not contain branches

Yeah, it seems that the time the mirror was created there were no release branches and therefore nothing was exported :) On Fri, Nov 20, 2015 at 8:13 PM, Hans Wennborg <hans at chromium.org> wrote: > On Thu, Nov 19, 2015 at 2:38 PM, Martell Malone via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hi All, >> >> I am currently trying to test out a few things

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

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

> > If you want to define an alias symbol "bar" to "foo" (which is an > extension you want to provide), one way is to create an object file that > defines "bar" and "__imp_bar" as aliases to "foo" and "__imp_foo", > respectively, and add that object file to the import library. As a result, > the import library file

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

> > The header of libuser32b.a says that it defines MessageBoxB and > __imp_MessageBoxB, but the import library file in the archive actually > defines MessageBoxA (not B). So the archive file is broken. You may want to > fix the header and try again. Yes this is how I done the alias. If you consider this invalid then look at libuser32.a The header defines MessageBoxA and

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

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

Hi, I'd like to submit a patch to match the clang patch on the front end. http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140414/103257.html The front end doesn't need this patch to work but it's still important. This is mostly based on work done by kai from redstar.de Could I get some feedback on this? I'm not sure if the emitting of the register names will effect

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

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

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

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

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? > >

Would it be possible to share a repro.tar file created with /linkrepro so that we can reproduce the problem? Peter On Thu, May 11, 2017 at 3:00 AM, Martell Malone <martellmalone at gmail.com> wrote: > There are a few things running in parallel and thanks for taking the time > to review and help me get this in tree. > I wanted to follow up with a question on the linker side of

Hi Martell, r289280 was not intended to be a significant functional change in the sense that it would cause programs to fail to link, so this may be a bug I introduced in r289280 (or one of the followup patches, which also changed link order). How is crt0_c.c being added to the link? If crt0_c.c is supplying a definition of the main function I would expect it to be in an archive which would

> > I will not be stripping out any of the existing CMake. If we go down this > path what I’m going to do is refactor the CMake to produce to logically > separated projects so that the builtins can be built with or without the > runtime libraries. It will all still be CMake-based. Sorry. s/stripping/seperating/g I was still thinking about the stripping of the IOS build from the OSX

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: > >