search for: __ctor_list__

...rtbegin.bc' target datalayout = "E-p:32:32:128-i1:8:128-i8:8:128-i16:16:128-i32:32:128-i64:32:128-f32:32:128-f64:64:128-v64:64:64-v128:128:128-a0:0:128-s0:128:128" target triple = "spu" @__dso_handle = hidden global i8* null, align 16 ; <i8**> [#uses=0] @__CTOR_LIST__ = internal global [1 x void ()*] [ void ()* inttoptr (i64 4294967295 to void ()*) ], section ".ctors", align 4 ; <[1 x void ()*]*> [#uses=1] @__DTOR_LIST__ = internal global [1 x void ()*] [ void ()* inttoptr (i64 4294967295 to void ()*) ], section ".dtors",...

...x > je .LBB2_3 #UnifiedReturnBlock > .LBB2_2: #cond_true10 > leaq __JCR_LIST__(%rip), %rdi > call *%rax > movq %rbp, %rsp > popq %rbp > ret > .LBB2_3: #UnifiedReturnBlock > movq %rbp, %rsp > popq %rbp > ret > .size frame_dummy, .-frame_dummy > .type __CTOR_LIST__, at object > .section .ctors,"aw", at progbits > .align 8 > __CTOR_LIST__: # __CTOR_LIST__ > .size __CTOR_LIST__, 8 > .quad 4294967295 > > .type __DTOR_LIST__, at object > .section .dtors,"aw", at progbits > .align 8 > __DTOR_LIST__: # __...

...ith __used__ attributes in llvm-gcc/gcc/crtstuff.c. GCC compiles crtstuff.c with -fno-toplevel-reorder option, which ensures that unused static globals are not removed during optimization. However, since LLVM does not support that option, I presume __used__ attribute is used instead. For example, __CTOR_LIST__[1] definition is changed as follows: STATIC func_ptr __CTOR_LIST__[1] /* LLVM LOCAL begin */ #ifdef __llvm__ __attribute__ ((__used__, aligned(sizeof(func_ptr)))) #else __attribute__ ((__unused__, aligned(sizeof(func_ptr)))) #endif /* LLVM LOCAL end */ = { (func_ptr) (-1) }; Note that __unu...

...i > > call *%rax > > movq %rbp, %rsp > > popq %rbp > > ret > > .LBB2_3: #UnifiedReturnBlock > > movq %rbp, %rsp > > popq %rbp > > ret > > .size frame_dummy, .-frame_dummy > > .type __CTOR_LIST__, at object > > .section .ctors,"aw", at progbits > > .align 8 > > __CTOR_LIST__: # __CTOR_LIST__ > > .size __CTOR_LIST__, 8 > > .quad 4294967295 > > > > .type __DTOR_LIST__, at object >...

Hi all, I've run into problems compiling the llvm-gcc frontend on x86_64. Is this not supported, or am I making an error somewhere? The procedure I followed was: 1. Download LLVM 2.0 source as a tarball (from a few days ago, during the testing phase). 2. Download the llvm-gcc4 source today, as a tarball. 3. Extract both. 4. Configure LLVM as: ../src/configure --prefix=`pwd`../install

Updated set of patches for coverage. Changes: - change copyright lines - use gcov: instead of cover: in commit comment - use #ifdef in xen/common/sysctl.c instead of dummy inline function - added base documentation in docs/misc - added -h option to xencov

+llvmdev, -llvm-dev On Tue, Jun 26, 2012 at 2:28 PM, Kostya Serebryany <kcc at google.com> wrote: > Hi Reid, > > On Tue, Jun 26, 2012 at 4:30 AM, Reid Watson <reidw at google.com> wrote: > >> Hello, >> >> I'm starting work on a project to detect initialization order problems >> in C++ files using AddressSanitizer. >> The extension in

...IZEOF_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));...

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

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,

...ET_VECTOR_ELT U STRING_ELT U TYPEOF U VECTOR_ELT 0000000000208040 d VersionInfoFieldNames 00000000002080c0 a _DYNAMIC 0000000000208308 a _GLOBAL_OFFSET_TABLE_ w _Jv_RegisterClasses 0000000000208008 d __CTOR_END__ 0000000000208000 d __CTOR_LIST__ 0000000000208018 d __DTOR_END__ 0000000000208010 d __DTOR_LIST__ 0000000000007e58 r __FRAME_END__ 0000000000208020 d __JCR_END__ 0000000000208020 d __JCR_LIST__ 000000000020aee0 A __bss_start w __cxa_finalize@@GLIBC_2.2.5 0000000000006e20 t __do_global_ctors_aux 0000000000003890 t...

...ET_VECTOR_ELT U STRING_ELT U TYPEOF U VECTOR_ELT 0000000000208040 d VersionInfoFieldNames 00000000002080c0 a _DYNAMIC 0000000000208308 a _GLOBAL_OFFSET_TABLE_ w _Jv_RegisterClasses 0000000000208008 d __CTOR_END__ 0000000000208000 d __CTOR_LIST__ 0000000000208018 d __DTOR_END__ 0000000000208010 d __DTOR_LIST__ 0000000000007e58 r __FRAME_END__ 0000000000208020 d __JCR_END__ 0000000000208020 d __JCR_LIST__ 000000000020aee0 A __bss_start w __cxa_finalize@@GLIBC_2.2.5 0000000000006e20 t __do_global_ctors_aux 0000000000003890 t...

This round implements all of the review comments from V2 and all patches are now acked. Unless there are any objections I intend to apply later this morning. Ian.