From nobody Thu May 16 18:26:37 2024 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VgJTR4RnKz5Lfrj for ; Thu, 16 May 2024 18:26:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4VgJTR1Snqz4Xmd; Thu, 16 May 2024 18:26:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 44GIQbtP012726; Thu, 16 May 2024 21:26:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 44GIQbtP012726 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 44GIQbUb012725; Thu, 16 May 2024 21:26:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 16 May 2024 21:26:37 +0300 From: Konstantin Belousov To: Zhenlei Huang Cc: FreeBSD Current Subject: Re: gcc behavior of init priority of .ctors and .dtors section Message-ID: References: <3ECF8C28-D2D9-4212-B025-3EC64E46BADC@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3ECF8C28-D2D9-4212-B025-3EC64E46BADC@FreeBSD.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4VgJTR1Snqz4Xmd On Thu, May 16, 2024 at 08:06:46PM +0800, Zhenlei Huang wrote: > Hi, > > I'm recently working on https://reviews.freebsd.org/D45194 and got noticed > that gcc behaves weirdly. > > A simple source file to demonstrate that. > > ``` > # cat ctors.c > > #include > > __attribute__((constructor(101))) void init_101() { puts("init 1"); } > __attribute__((constructor(65535))) void init_65535() { puts("init 3"); } > __attribute__((constructor)) void init() { puts("init 4"); } > __attribute__((constructor(65535))) void init_65535_2() { puts("init 5"); } > __attribute__((constructor(65534))) void init_65534() { puts("init 2"); } > > int main() { puts("main"); } > > __attribute__((destructor(65534))) void fini_65534() { puts("fini 2"); } > __attribute__((destructor(65535))) void fini_65535() { puts("fini 3"); } > __attribute__((destructor)) void fini() { puts("fini 4"); } > __attribute__((destructor(65535))) void fini_65535_2() { puts("fini 5"); } > __attribute__((destructor(101))) void fini_101() { puts("fini 1"); } > > # clang ctors.c && ./a.out > init 1 > init 2 > init 3 > init 4 > init 5 > main > fini 5 > fini 4 > fini 3 > fini 2 > fini 1 > ``` > > clang with the option -fno-use-init-array and run will produce the same result, which > is what I expected. Why do you add that switch? > > 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.