search for: fini_array

From: Matt Fleming <matt.fleming at intel.com> GCC 4.7 now places pointers to functions with the 'constructor' and 'destructor' function attributes in .init_array and .fini_array sections, respectively, whereas previously they were in the .ctors and .dtors sections. This change breaks the ctors/dtors code as it only expects function to be in the .ctors and .dtors sections, meaning the ctors and dtors functions are never executed. While a COM32_INIT() macro exists that plac...

...mbols and configure DT_INIT/DT_FINI tags. This behaviour exactly corresponds to the GNU linker. By the way symbols specified in the -init/-fini options can be in any sections, not only .init/.fini. 2. -init-array/-fini-array options (I still not sure we need this functionality) affect .init_array/.fini_array and DT_INIT_ARRAY/DT_FINI_ARRAY tags. The order of these options define priority. The only problem is that we cannot setup priority of DT_INIT vs DT_INIT_ARRAY. -- Simon Atanasyan

...the data section more isolated than the gold or bfd linkers. For example, readelf -l applied to the "same" executable linked with those three linkers reveals the following under "Section to Segment mapping": lld: 05 .data .got.plt .bss gold: 03 .eh_frame .init_array .fini_array .preinit_array .dynamic .got .got.plt .data .bss bfd: 05 .eh_frame .preinit_array .init_array .fini_array .dynamic .got .got.plt .data .bss This separation seems to result in lld creating two LOAD RW segments whenever gold or bfd would create only one. For example, also from readelf -l outpu...

Hi, The LLD linker in gnu flavor mode accepts multiple -init/-fini command line options. For _all_ symbols specified by these options the linker creates appropriate entries in the .init_array/.fini_array sections. But it looks like LD and Gold linkers do not support this feature and take in account only the last -init/-fini options. % cat foo.c int a = 0; void foo() { a += 1; } void bar() { a += 2; } % cat main.c extern int a; int printf(const char *, ...); int main() { printf("a: %d\n"...

From: Matt Fleming <matt.fleming at intel.com> Here are the patches that I've got queued up based on the very helpful feedback I received from people testing Syslinux 5.00-pre9. Unless anyone has any concerns these will make it into Syslinux 5.00-pre10. Matt Fleming (9): pxe: Don't call open_config() from the pxe core ldlinux: Print a warning if no config file is found

...nit_array : + { + PROVIDE_HIDDEN (__init_array_start = .); + KEEP (*(SORT_BY_INIT_PRIORITY(.init_array.*) SORT_BY_INIT_PRIORITY(.ctors.*))) + KEEP (*(.init_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) .ctors)) + PROVIDE_HIDDEN (__init_array_end = .); + } + .fini_array : + { + PROVIDE_HIDDEN (__fini_array_start = .); + KEEP (*(SORT_BY_INIT_PRIORITY(.fini_array.*) SORT_BY_INIT_PRIORITY(.dtors.*))) + KEEP (*(.fini_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) .dtors)) + PROVIDE_HIDDEN (__fini_array_end = .); + } + .jcr...

...nit_array : + { + PROVIDE_HIDDEN (__init_array_start = .); + KEEP (*(SORT_BY_INIT_PRIORITY(.init_array.*) SORT_BY_INIT_PRIORITY(.ctors.*))) + KEEP (*(.init_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) .ctors)) + PROVIDE_HIDDEN (__init_array_end = .); + } + .fini_array : + { + PROVIDE_HIDDEN (__fini_array_start = .); + KEEP (*(SORT_BY_INIT_PRIORITY(.fini_array.*) SORT_BY_INIT_PRIORITY(.dtors.*))) + KEEP (*(.fini_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) .dtors)) + PROVIDE_HIDDEN (__fini_array_end = .); + } + .jcr...

...which isn't pretty. */ - . = ALIGN(32 / 8); - PROVIDE (__preinit_array_start = .); - .preinit_array : { *(.preinit_array) } - PROVIDE (__preinit_array_end = .); - PROVIDE (__init_array_start = .); - .init_array : { *(.init_array) } - PROVIDE (__init_array_end = .); - PROVIDE (__fini_array_start = .); - .fini_array : { *(.fini_array) } - PROVIDE (__fini_array_end = .); - .data : - { - _fdata = . ; - *(.data .data.* .gnu.linkonce.d.*) - SORT(CONSTRUCTORS) - } - .data1 : { *(.data1) } - .tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) } - .tbss...

...= .); - KEEP (*(SORT(.preinit_array*))) - KEEP (*(SORT(.init_array*))) - KEEP (*(SORT(.ctors*))) - HIDDEN(__ctors_end = .); - } - - HIDDEN(__dtors_vma = .); - HIDDEN(__dtors_lma = __dtors_vma + __text_lma - __text_vma); - .dtors : AT(__dtors_lma) { - HIDDEN(__dtors_start = .); - KEEP (*(SORT(.fini_array*))) - KEEP (*(SORT(.dtors*))) - HIDDEN(__dtors_end = .); - } - - . = ALIGN(4); - - HIDDEN(__dynsym_vma = .); - HIDDEN(__dynsym_lma = __dynsym_vma + __text_lma - __text_vma); - .dynsym : AT(__dynsym_lma) { - HIDDEN(__dynsym_start = .); - *(.dynsym) - HIDDEN(__dynsym_end = .); - } - HIDDEN(__dyn...

...__ ((__unused__, aligned(sizeof(func_ptr)))) #endif /* LLVM LOCAL end */ = { (func_ptr) (-1) }; Note that __unused__ just suppresses the warning that __CTOR_LIST__ is not used. My question is that why some global static variables, such as __frame_dummy_init_array_entry and __do_global_dtors_aux_fini_array_entry, are not given __used__ attributes. It seems that llvm-gcc removes these variables and causes .init_array and .fini_array section to be empty. Linker complains about this as in "ld: warning: .init_array section has zero size". Also, I verified that frame_dummy and __do_global_dtors_...

Hi All, The general initializer support patch has landed (see 85fb997659b plus follow up fixes). Some quick background: Until now ORC, like MCJIT, has handled static initializer discovery by searching for llvm.global_ctors and llvm.global_dtors arrays in the IR added to the JIT. This approach suffers from several drawbacks: 1) It provides no built-in support for other program representations:

Hi, I noticed that klibc started crashing on 64-bit MIPS and in my quest to fix the bug I got a bit carried away and fixed a few other things as well. Here are various miscellaneous MIPS patches, although the first patch is the important one. Thanks, James *** BLURB HERE *** James Cowgill (5): mips64: compile with -mno-abicalls mips: use -Ttext-segment when linking shared library

...which isn't pretty. */ + . = ALIGN(32 / 8); + PROVIDE (__preinit_array_start = .); + .preinit_array : { *(.preinit_array) } + PROVIDE (__preinit_array_end = .); + PROVIDE (__init_array_start = .); + .init_array : { *(.init_array) } + PROVIDE (__init_array_end = .); + PROVIDE (__fini_array_start = .); + .fini_array : { *(.fini_array) } + PROVIDE (__fini_array_end = .); + .data : + { + _fdata = . ; + *(.data .data.* .gnu.linkonce.d.*) + SORT(CONSTRUCTORS) + } + .data1 : { *(.data1) } + .tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) } + .tbss...

From: Sylvain Gault <sylvain.gault at gmail.com> These patches basically remove unused linker scripts and port a change that was made to an unused script. Those are to be applied on top of the gcc 5 bug fixes as they would conflict otherwise. Sylvain Gault (4): diag/mbr: fix dependency to linker script Remove unused linker scripts core: Make symbols defined in linker script HIDDEN

...shankare at codeaurora.org> wrote: > On 12/8/2014 11:09 AM, Joerg Sonnenberger wrote: >> >> On Mon, Dec 08, 2014 at 10:21:49AM -0600, Shankar Easwaran wrote: >>> >>> The DT_INIT/DT_FINI correspond to one initializer function,where as >>> DT_INIT_ARRAY/DT_FINI_ARRAY is used when there is more than one >>> initalizer function/finalizer function respectively. >> >> This is not true. The difference is that the DT_INIT / DT_FINI function >> is responsible for calling into the .init / .fini block and for >> DT_INIT_ARRAY / DT_FINI_A...

...which isn't pretty. */ + . = ALIGN(32 / 8); + PROVIDE (__preinit_array_start = .); + .preinit_array : { *(.preinit_array) } + PROVIDE (__preinit_array_end = .); + PROVIDE (__init_array_start = .); + .init_array : { *(.init_array) } + PROVIDE (__init_array_end = .); + PROVIDE (__fini_array_start = .); + .fini_array : { *(.fini_array) } + PROVIDE (__fini_array_end = .); + .data : + { + _fdata = . ; + *(.data .data.* .gnu.linkonce.d.*) + SORT(CONSTRUCTORS) + } + .data1 : { *(.data1) } + .tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) } + .tbss...

Hi Rafael, On 07/31/2017 04:20 PM, Rafael Avila de Espindola via llvm-dev wrote: > However, do we need to start with instrumentation? The original paper > uses sampling with good results and current intel cpus can record every > branch in a program. > > I would propose starting with just an lld patch that reads the call > graph from a file. The format would be very similar to

...iter<ELFT>::createSections() { Old.end()); Script->fabricateDefaultCommands(); + sortByCFGProfile<ELFT>(OutputSections); sortBySymbolsOrder<ELFT>(); sortInitFini(findSection(".init_array")); sortInitFini(findSection(".fini_array"));

...LFT>::createSections() { if (IS) Factory.addInputSec(IS, getOutputSectionName(IS->Name)); + sortByCFGProfile<ELFT>(OutputSections); sortBySymbolsOrder<ELFT>(OutputSections); sortInitFini(findSection(".init_array")); sortInitFini(findSection(".fini_array")); -------------- next part -------------- diff --git a/include/llvm/InitializePasses.h b/include/llvm/InitializePasses.h index abb0aa3..93084d8 100644 --- a/include/llvm/InitializePasses.h +++ b/include/llvm/InitializePasses.h @@ -85,6 +85,7 @@ void initializeBreakCriticalEdgesPass(PassRegis...

...FT> void Writer<ELFT>::createSections() { Old.end()); Script->fabricateDefaultCommands(); + sortByCFGProfile<ELFT>(); sortBySymbolsOrder<ELFT>(); sortInitFini(findSection(".init_array")); sortInitFini(findSection(".fini_array")); -------------- next part -------------- 6646528 __memmove_sse2_unaligned __memmove_sse2_unaligned_erms 6630292 _ZN3lld3elf15scanRelocationsIN4llvm6object7ELFTypeILNS2_7support10endiannessE1ELb1EEEEEvRNS0_16InputSectionBaseE _ZNK3lld3elf10SymbolBody13isPreemptibleEv 6428622 __malloc _int_ma...