Re: gcc behavior of init priority of .ctors and .dtors section
- In reply to: Lorenzo Salvadore : "Re: gcc behavior of init priority of .ctors and .dtors section"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 16 May 2024 20:13:50 UTC
On Thu, May 16, 2024 at 08:05:57PM +0000, Lorenzo Salvadore wrote: > On Thursday, May 16th, 2024 at 20:26, Konstantin Belousov <kostikbel@gmail.com> wrote: > > > gcc13 from ports > > > `# gcc ctors.c && ./a.out init 1 init 2 init 5 init 4 init 3 main fini 3 fini 4 fini 5 fini 2 fini 1` > > > > > > The above order is not expected. I think clang's one is correct. > > > > > > Further hacking with readelf shows that clang produces the right order of > > > section .rela.ctors but gcc does not. > > > > > > ``` > > > # clang -fno-use-init-array -c ctors.c && readelf -r ctors.o | grep 'Relocation section with addend (.rela.ctors)' -A5 > clang.txt > > > # gcc -c ctors.c && readelf -r ctors.o | grep 'Relocation section with addend (.rela.ctors)' -A5 > gcc.txt > > > # diff clang.txt gcc.txt > > > 3,5c3,5 > > > < 000000000000 000800000001 R_X86_64_64 0000000000000060 init_65535_2 + 0 > > > < 000000000008 000700000001 R_X86_64_64 0000000000000040 init + 0 > > > < 000000000010 000600000001 R_X86_64_64 0000000000000020 init_65535 + 0 > > > --- > > > > > > > 000000000000 000600000001 R_X86_64_64 0000000000000011 init_65535 + 0 > > > > 000000000008 000700000001 R_X86_64_64 0000000000000022 init + 0 > > > > 000000000010 000800000001 R_X86_64_64 0000000000000033 init_65535_2 + 0 > > > > ``` > > > > > > The above show clearly gcc produces the wrong order of section `.rela.ctors`. > > > > > > Is that expected behavior ? > > > > > > I have not tried Linux version of gcc. > > > > Note that init array vs. init function behavior is encoded by a note added > > by crt1.o. I suspect that the problem is that gcc port is built without > > --enable-initfini-array configure option. > > Indeed, support for .init_array and .fini_array has been added to the GCC ports > but is present in the *-devel ports only for now. I will > soon proceed to enable it for the GCC standard ports too. lang/gcc14 is soon > to be added to the ports tree and will have it since the beginning. It is not 'support', but a bug. For very long time, crt1.o instructs rtld to use initarray instead of initfunc. gcc generates broken binaries trying to use initfunc. > > If this is indeed the issue, switching to a -devel GCC port should fix it. > > Cheers, > > Lorenzo Salvadore