search for: __image_base__

...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 references against > __ImageBase will be resolved using __image_base__. > Or you could have your wrapper driver pa...

...ence.) > > 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 references against > __ImageBase will be resolved using __image_base__. > > > Or you could have your wrapper driv...

...ence.) > > 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 references against > __ImageBase will be resolved using __image_base__. > > > Or you could have your wrapper driv...

...ence.) > > 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 references against > __ImageBase will be resolved using __image_base__. > > > Or you could have your wrapper driv...

...9;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 Malone <martellmalone at gmail.com> > wrote: > >> I wonder if it can be a wrapper for LLD/COFF....

...: undefined symbol: __bss_end__ lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __RUNTIME_PSEUDO_RELOC_LIST__ lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __RUNTIME_PSEUDO_RELOC_LIST_END__ lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __image_base__ They seem to come from the default cygwin ld linker script, pasted below: GNU ld (GNU Binutils) 2.29.1.20171006 Supported emulations: i386pep i386pe using internal linker script: ================================================== /* Default linker script, for normal executables */ /* Cop...

..._ > lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: > __RUNTIME_PSEUDO_RELOC_LIST__ > lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: > __RUNTIME_PSEUDO_RELOC_LIST_END__ > lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: > __image_base__ > > > They seem to come from the default cygwin ld linker script, pasted below: > > GNU ld (GNU Binutils) 2.29.1.20171006 > Supported emulations: > i386pep > i386pe > using internal linker script: > ================================================== > /* Def...

COFF lld doesn't support the linker script at the moment, and I'm sad to say that it is very unlikely to support that in the future. Linker script support is so huge that I can't imagine we really want it for COFF. GNU BFD linker supports it because the linker is built as an interpreter for the built-in linker script (and that's one of the reasons why GNU linker is by far more

Hello, I have a user who is trying to get LLD to link for the cygwin target: https://github.com/zig-lang/zig/issues/751 Currently the issue they are running into is needing to define a linker script, but the COFF driver (or MinGW driver) does not have support for that. Is there documentation or advice for how to use LLD to link for cygwin? As a starting point, which driver to use? Regards,

Hello, This series has been split into two patches, one for arm and one for x86. I figured that this was easier than doing it as a single combined patch, especially as the changes are functionally independent. x86 has been boot tested, but arm has not even been compile tested as I lack a suitable cross compiler. However, the changes are just text replacement, so I dont expect any issues. The

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