[llvm-dev] LLD: targeting cygwin
Andrew Kelley via llvm-dev
llvm-dev at lists.llvm.org
Fri Feb 9 13:15:05 PST 2018
I believe my user has forked LLD and is experimenting and will report back
with findings.
On Thu, Feb 8, 2018 at 11:26 PM, Rui Ueyama <ruiu at google.com> wrote:
> Is that the only problem to use lld to link cygwin programs?
>
> On Thu, Feb 8, 2018 at 8:19 AM, Andrew Kelley <superjoe30 at gmail.com>
> wrote:
>
>> Here are the linker errors:
>>
>> lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol:
>> __data_start__
>> lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol:
>> __data_end__
>> lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol:
>> __bss_start__
>> lld: warning: libcygwin.a(_cygwin_crt0_common.o): 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 */
>> /* Copyright (C) 2014-2017 Free Software Foundation, Inc.
>> Copying and distribution of this script, with or without modification,
>> are permitted in any medium without royalty provided the copyright
>> notice and this notice are preserved. */
>> OUTPUT_FORMAT(pei-x86-64)
>> SEARCH_DIR("/usr/x86_64-pc-cygwin/lib"); SEARCH_DIR("/usr/lib");
>> SEARCH_DIR("/usr/lib/w32api");
>> SECTIONS
>> {
>> /* Make the virtual address and file offset synced if the alignment is
>> lower than the target page size. */
>> . = SIZEOF_HEADERS;
>> . = ALIGN(__section_alignment__);
>> .text __image_base__ + ( __section_alignment__ < 0x1000 ? . :
>> __section_alignment__ ) :
>> {
>> KEEP(*(.init))
>> *(.text)
>> *(SORT(.text$*))
>> *(.text.*)
>> *(.gnu.linkonce.t.*)
>> *(.glue_7t)
>> *(.glue_7)
>> . = ALIGN(8);
>> ___CTOR_LIST__ = .; __CTOR_LIST__ = . ;
>> LONG (-1); LONG (-1);
>> KEEP (*(.ctors));
>> KEEP (*(.ctor));
>> KEEP (*(SORT(.ctors.*)));
>> LONG (0); LONG (0);
>> ___DTOR_LIST__ = .; __DTOR_LIST__ = . ;
>> LONG (-1); LONG (-1);
>> KEEP (*(.dtors));
>> KEEP (*(.dtor));
>> KEEP (*(SORT(.dtors.*)));
>> LONG (0); LONG (0);
>> KEEP (*(.fini))
>> /* ??? Why is .gcc_exc here? */
>> *(.gcc_exc)
>> PROVIDE (etext = .);
>> KEEP (*(.gcc_except_table))
>> }
>> /* The Cygwin32 library uses a section to avoid copying certain data
>> on fork. This used to be named ".data". The linker used
>> to include this between __data_start__ and __data_end__, but that
>> breaks building the cygwin32 dll. Instead, we name the section
>> ".data_cygwin_nocopy" and explicitly include it after __data_end__.
>> */
>> .data BLOCK(__section_alignment__) :
>> {
>> __data_start__ = . ;
>> *(.data)
>> *(.data2)
>> *(SORT(.data$*))
>> KEEP(*(.jcr))
>> __data_end__ = . ;
>> *(.data_cygwin_nocopy)
>> }
>> .rdata BLOCK(__section_alignment__) :
>> {
>> *(.rdata)
>> *(SORT(.rdata$*))
>> __rt_psrelocs_start = .;
>> KEEP(*(.rdata_runtime_pseudo_reloc))
>> __rt_psrelocs_end = .;
>> }
>> __rt_psrelocs_size = __rt_psrelocs_end - __rt_psrelocs_start;
>> ___RUNTIME_PSEUDO_RELOC_LIST_END__ = .;
>> __RUNTIME_PSEUDO_RELOC_LIST_END__ = .;
>> ___RUNTIME_PSEUDO_RELOC_LIST__ = . - __rt_psrelocs_size;
>> __RUNTIME_PSEUDO_RELOC_LIST__ = . - __rt_psrelocs_size;
>> .eh_frame BLOCK(__section_alignment__) :
>> {
>> KEEP (*(.eh_frame*))
>> }
>> .pdata BLOCK(__section_alignment__) :
>> {
>> KEEP(*(.pdata*))
>> }
>> .xdata BLOCK(__section_alignment__) :
>> {
>> KEEP(*(.xdata*))
>> }
>> .bss BLOCK(__section_alignment__) :
>> {
>> __bss_start__ = . ;
>> *(.bss)
>> *(COMMON)
>> __bss_end__ = . ;
>> }
>> .edata BLOCK(__section_alignment__) :
>> {
>> *(.edata)
>> }
>> /DISCARD/ :
>> {
>> *(.debug$S)
>> *(.debug$T)
>> *(.debug$F)
>> *(.drectve)
>> *(.note.GNU-stack)
>> *(.gnu.lto_*)
>> }
>> .idata BLOCK(__section_alignment__) :
>> {
>> /* This cannot currently be handled with grouped sections.
>> See pep.em:sort_sections. */
>> KEEP (SORT(*)(.idata$2))
>> KEEP (SORT(*)(.idata$3))
>> /* These zeroes mark the end of the import list. */
>> LONG (0); LONG (0); LONG (0); LONG (0); LONG (0);
>> KEEP (SORT(*)(.idata$4))
>> __IAT_start__ = .;
>> SORT(*)(.idata$5)
>> __IAT_end__ = .;
>> KEEP (SORT(*)(.idata$6))
>> KEEP (SORT(*)(.idata$7))
>> }
>> .CRT BLOCK(__section_alignment__) :
>> {
>> ___crt_xc_start__ = . ;
>> KEEP (*(SORT(.CRT$XC*))) /* C initialization */
>> ___crt_xc_end__ = . ;
>> ___crt_xi_start__ = . ;
>> KEEP (*(SORT(.CRT$XI*))) /* C++ initialization */
>> ___crt_xi_end__ = . ;
>> ___crt_xl_start__ = . ;
>> KEEP (*(SORT(.CRT$XL*))) /* TLS callbacks */
>> /* ___crt_xl_end__ is defined in the TLS Directory support code */
>> ___crt_xp_start__ = . ;
>> KEEP (*(SORT(.CRT$XP*))) /* Pre-termination */
>> ___crt_xp_end__ = . ;
>> ___crt_xt_start__ = . ;
>> KEEP (*(SORT(.CRT$XT*))) /* Termination */
>> ___crt_xt_end__ = . ;
>> }
>> /* Windows TLS expects .tls$AAA to be at the start and .tls$ZZZ to be
>> at the end of the .tls section. This is important because
>> _tls_start MUST
>> be at the beginning of the section to enable SECREL32 relocations
>> with TLS
>> data. */
>> .tls BLOCK(__section_alignment__) :
>> {
>> ___tls_start__ = . ;
>> KEEP (*(.tls$AAA))
>> KEEP (*(.tls))
>> KEEP (*(.tls$))
>> KEEP (*(SORT(.tls$*)))
>> KEEP (*(.tls$ZZZ))
>> ___tls_end__ = . ;
>> }
>> .endjunk BLOCK(__section_alignment__) :
>> {
>> /* end is deprecated, don't use it */
>> PROVIDE (end = .);
>> PROVIDE ( _end = .);
>> __end__ = .;
>> }
>> .rsrc BLOCK(__section_alignment__) : SUBALIGN(4)
>> {
>> KEEP (*(.rsrc))
>> KEEP (*(.rsrc$*))
>> }
>> .reloc BLOCK(__section_alignment__) :
>> {
>> *(.reloc)
>> }
>> .stab BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.stab)
>> }
>> .stabstr BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.stabstr)
>> }
>> /* DWARF debug sections.
>> Symbols in the DWARF debugging sections are relative to the beginning
>> of the section. Unlike other targets that fake this by putting the
>> section VMA at 0, the PE format will not allow it. */
>> /* DWARF 1.1 and DWARF 2. */
>> .debug_aranges BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_aranges)
>> }
>> .zdebug_aranges BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.zdebug_aranges)
>> }
>> .debug_pubnames BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_pubnames)
>> }
>> .zdebug_pubnames BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.zdebug_pubnames)
>> }
>> .debug_pubtypes BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_pubtypes)
>> }
>> .zdebug_pubtypes BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.zdebug_pubtypes)
>> }
>> /* DWARF 2. */
>> .debug_info BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_info .gnu.linkonce.wi.*)
>> }
>> .zdebug_info BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.zdebug_info .zdebug.gnu.linkonce.wi.*)
>> }
>> .debug_abbrev BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_abbrev)
>> }
>> .zdebug_abbrev BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.zdebug_abbrev)
>> }
>> .debug_line BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_line)
>> }
>> .zdebug_line BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.zdebug_line)
>> }
>> .debug_frame BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_frame)
>> }
>> .zdebug_frame BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.zdebug_frame)
>> }
>> .debug_str BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_str)
>> }
>> .zdebug_str BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.zdebug_str)
>> }
>> .debug_loc BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_loc)
>> }
>> .zdebug_loc BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.zdebug_loc)
>> }
>> .debug_macinfo BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_macinfo)
>> }
>> .zdebug_macinfo BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.zdebug_macinfo)
>> }
>> /* SGI/MIPS DWARF 2 extensions. */
>> .debug_weaknames BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_weaknames)
>> }
>> .zdebug_weaknames BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.zdebug_weaknames)
>> }
>> .debug_funcnames BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_funcnames)
>> }
>> .zdebug_funcnames BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.zdebug_funcnames)
>> }
>> .debug_typenames BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_typenames)
>> }
>> .zdebug_typenames BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.zdebug_typenames)
>> }
>> .debug_varnames BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_varnames)
>> }
>> .zdebug_varnames BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.zdebug_varnames)
>> }
>> .debug_macro BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_macro)
>> }
>> .zdebug_macro BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.zdebug_macro)
>> }
>> /* DWARF 3. */
>> .debug_ranges BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_ranges)
>> }
>> .zdebug_ranges BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.zdebug_ranges)
>> }
>> /* DWARF 4. */
>> .debug_types BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_types .gnu.linkonce.wt.*)
>> }
>> .zdebug_types BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.zdebug_types .zdebug.gnu.linkonce.wt.*)
>> }
>> /* For Go and Rust. */
>> .debug_gdb_scripts BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_gdb_scripts)
>> }
>> .zdebug_gdb_scripts BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.zdebug_gdb_scripts)
>> }
>> }
>>
>> On Wed, Feb 7, 2018 at 6:24 PM, Rui Ueyama <ruiu at google.com> wrote:
>>
>>> 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 complicated than lld), but that's not the case for lld.
>>>
>>> So, "support linker script" is a huge feature request that we are very
>>> unlikely to fulfill. But I don't think that you actually need all the
>>> features of the linker script. If you have some specific need, please
>>> explain. We may be able to help.
>>>
>>> On Wed, Feb 7, 2018 at 3:10 PM, Andrew Kelley via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> 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,
>>>> Andrew
>>>>
>>>> _______________________________________________
>>>> 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/20180209/d934f768/attachment.html>
More information about the llvm-dev
mailing list