search for: init_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...

On Mon, Dec 8, 2014 at 10:57 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > The dynamic loader handles only one entry for DT_INIT. If there is more than > one init option, we could convert this as an .init_array instead ? > > If that doesnot work, we can come up with a .init_array option but I am not > sure about how will you handle priority with init_array's ? Do you set > linker defined init/fini symbols the last in priority ? My idea: 1. -init/-fini options affects DT_INIT/DT_FINI tags...

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

Hi guys, I am trying to use the indvars pass, but i don't see any changes in the IL representation. For this simple function void init_array(int k) { int A[20]; for (int i=2; i<10; i++) A[i] = 0; } i run *clang test-simple.c -S -emit-llvm -o test.il* and i obtain the following il representation define void @init_array(i32 %k) nounwind { entry: %k.addr = alloca i32, align 4 %A = alloca [20 x i32], align 4 %i =...

...serted by the compiler/assembler C) When merging section A from inputs B and C, the minimal amount of padding necessary so that the first symbol from C is properly aligned is inserted. I think(?) these conditions would be sufficient to guarantee, for example, that I could implement my own .ctor / @init_array logic using only the front end. And are there any subtle interactions here with -fdata-sections or behavioral differences across COFF/ELF/MachO? Is there anyone who can provide some insight on this? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.l...

On Sun, Jun 19, 2011 at 7:21 AM, Sorin Baltateanu <baltateanu.sorin at gmail.com> wrote: > Hi guys, > > I am trying to use the indvars pass, but i don't see any changes in the IL > representation. > > For this simple function > > void init_array(int k) > { >     int A[20]; >     for (int i=2; i<10; i++) >         A[i] = 0; > } > > i run clang test-simple.c -S -emit-llvm -o test.il and i obtain the > following il representation > > define void @init_array(i32 %k) nounwind { > entry: >   %k.addr = alloc...

...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 ldlinux: Fix logic if no DEFAULT or UI directive is found ldlinux: get_key() requires raw access to user input com32: Include .init_array section in .ctors in linker script CLI: Fix command history traversal win: Fix installing to a directory win: Print error message if we fail to install to --directory CLI: Add Ctrl + V support for printing the Syslinux version com32/elflink/ldlinux/Makefile | 2 +- com32/elflink/ldli...

...which would be best design approach to solve. The aarch64 R_AARCH64_ABS64 relocation for PIC/PIE build requires a dynamic relocation (R_AARCH64_RELATIVE) with the value set as the addend of the relocation. For instance, when linking the crtbeginS.o which contains: Relocation section '.rela.init_array' at offset 0xd28 contains 1 entries: Offset Info Type Sym. Value Sym. Name + Addend 000000000000 000200000101 R_AARCH64_ABS64 0000000000000000 .text + d4 The resulting dynamic relocation on the shared object should be: Relocation section '.rela.dyn'...

Hi, I'd like to fix PR19590, which is about llvm.global_ctors containing functions that end up being empty after optimization (which causes the linker to add useless init_array entries to the output binary). globalopt removes empty functions from llvm.global_ctors, but by the time the function becomes empty globalopt has already run and it doesn't run again. I'm wondering what the best fix is: 1. Should globalopt run once more after all other passes have run? 2....

...at lld keeps 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 read...

Hi there, I am currently working on the native port of an embedded OS and trying to get static initialization to work. We have our own startup code to handle things before the main is called. When using gcc I acquire the function pointers to the initializer array and iterate over them. I asked on the llvm IRC channel and got this helpful guide [1] for gcc. Apparently it works in a similar way on

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

...nking one of those with TU2 can still cause a crash since the guard variable would be undefined. * It requires always outputting the guard variable. Since neither gcc nor clang implement this part of the ABI, I was thinking if there was a better way to do it. One interesting option is putting the .init_array of TU2 in the comdat. That is exactly what we do for windows. In fact, just passing -Xclang -mllvm -Xclang -enable-structor-comdat will avoids the crash in the above example. Given that this has been broken since forever, waiting a bit more for https://sourceware.org/bugzilla/show_bug.cgi?id=17350...

On Wed, Oct 12, 2016 at 10:53 AM, Hal Finkel <hfinkel at anl.gov> wrote: > I don't think that Clang/LLVM uses it by default on x86_64. If you're using -Ofast, however, that would explain it. I recommend looking at -O3 vs -O0 and make sure those are the same. -Ofast enables -ffast-math, which can legitimately cause differences. > The following tests pass at "-O3" and

On Wed, Feb 27, 2019 at 1:37 PM Peter Collingbourne <peter at pcc.me.uk> wrote: > > > On Tue, Feb 26, 2019 at 2:24 PM Rui Ueyama via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >> I've heard people say that they want to analyze dependencies between >> object files at the linker level so that they can run a whole-program

On Tue, Sep 17, 2013 at 11:29 AM, Reid Kleckner <rnk at google.com> wrote: > Wait, I have a terrible idea. Why don't we roll our own .init_array style > appending section? I think we can make this work for all toolchains we > support. > Andy and I talked about this, but I don't think its worth it. My opinion is: 1. For tool options (the top-level llc, opt, llvm-as etc. opts) it doesn't matter. 2. For experimental options...

...? Compiling simple Fortran code with DragonEgg: > cat matmul.f90 subroutine matmul(nx, ny, nz) implicit none integer :: nx, ny, nz real, dimension(nx, ny) :: A real, dimension(ny, nz) :: B real, dimension(nx, nz) :: C integer :: i, j, k real, volatile :: start, finish call init_array call cpu_time(start) do i = 1, nx do j = 1, nz C(i,j) = 0 do k = 1, ny C(i, j) = C(i, j) + A(i, k) * B(k, j) enddo enddo enddo call cpu_time(finish) print *, sum(C), maxval(C), minval(C) call flush() contains subroutine init_array implicit n...

...long dead or unused. Do we still need -join-liveintervals? :-) On Sep 17, 2013, at 12:03 PM, Daniel Dunbar <daniel at zuster.org> wrote: > On Tue, Sep 17, 2013 at 11:29 AM, Reid Kleckner <rnk at google.com> wrote: > Wait, I have a terrible idea. Why don't we roll our own .init_array style appending section? I think we can make this work for all toolchains we support. > > Andy and I talked about this, but I don't think its worth it. My opinion is: > 1. For tool options (the top-level llc, opt, llvm-as etc. opts) it doesn't matter. > 2. For experimental opt...

...ned(sizeof(func_ptr)))) #else __attribute__ ((__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 verif...

...xception_ranges : ONLY_IF_RW { *(.exception_ranges .exception_ranges*) } + /* Thread Local Storage sections */ + .tdata : + { + PROVIDE_HIDDEN (__tdata_start = .); + *(.tdata .tdata.* .gnu.linkonce.td.*) + } + .tbss : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) } + .preinit_array : + { + PROVIDE_HIDDEN (__preinit_array_start = .); + KEEP (*(.preinit_array)) + PROVIDE_HIDDEN (__preinit_array_end = .); + } + .init_array : + { + PROVIDE_HIDDEN (__init_array_start = .); + KEEP (*(SORT_BY_INIT_PRIORITY(.init_array.*) SORT_BY_INIT_PRIORITY(.ctors.*))) +...