From nobody Thu May 16 12:06:46 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 4Vg83308qgz5L8ML for ; Thu, 16 May 2024 12:06:55 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Vg8326jB1z4kgr for ; Thu, 16 May 2024 12:06:54 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1715861214; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=P46IqagoGh0UkhL5rscitx++RlVsLcvST9/H5LZSRlY=; b=cebMvcxUpf5XvryRwGJbxzlZivsUVTUSxVmkFLeW9HOd9h1qf42fYha1YGQLr8sfgZM7BB yCm30KmO/JWgJFzQpeBIT411nFFrKtOxNItdIfBUg84zYxsljQl9EpEeP5gC9fISQD0sqS zeQRrttRmlSAv3c9W27y9FyzHVlXDbIqaYs6lN218M71tjwHnKk9W5mHYvwzdfynNHrhyc H3pLKkcalnilVKDzKur19V1J66VZWOpI0AL7YzltY2D8gf87tlw1ecqNXIszYuIw7SxnEo kPDuusooVwiZK1YqXu3oAbu/PEcED3z0h20bK8i7mwBYzCbnyK69C6YDS7zV/w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1715861214; a=rsa-sha256; cv=none; b=mL3EI4BXfxUe05At4ayjOzvDOe74JU1Z68ESTrXUNb7yWu7YnppBP/i6dKEz6uEB8HdHQW ytrkgjTdcdF2arCwnhSjQ9QVFCic+ISQ/fCpRsunojwpE75H8dWIMWvgciYG9rt2zblQ7P XGUs//WovAZU7d0OfQLf99ufw3km24NAibx5BX+bLJsi3E4S0riWOnhfuDMg8hb/4IvJkR FSiELlLX3fRmzNLyVY7EZ4TlG3Nq3SxbpUo/u/r3H5AeEQwrlkfBwTvdnqzzqqkllet4I4 mxnXJUOSRumMWbkQ/z7xSTUzqcdqEV2LZpEZRy3X3m90RI6mUcPpbwdfhL3zzQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1715861214; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=P46IqagoGh0UkhL5rscitx++RlVsLcvST9/H5LZSRlY=; b=em6gFDcpv6wlCd63TzhPKtqNM+2hJALpu4hAcOTOTNCrmS/9gQbP1ioaVBdL9BEj9CbXsS KTV+QLTFx4UbA85PcOYNQttlvDzWt8gkABKIQN6M4p4aqtbZFUGTQl5OiuElN2+hRopYFm 8VsSXO2i/8/cW47/yIxH0QwIXpeBuZM4GUrvippSbPquRu5DKd+K0zyc3OSUCW8gwWeoWF 4MeB13W0uK0C3g+OQhIguXGcw/mS4OC9x/iPzxl+YRU8RwjDIXm3jF3GO/PfINTWq4y6fH RY+BzlxKqfezElKd30sNXq/StttGIu0DavTMXkLR42B5cpBXEvbPU6C8AgwJjg== Received: from smtpclient.apple (ns1.oxydns.net [45.32.91.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Vg8322fGLzhtM for ; Thu, 16 May 2024 12:06:54 +0000 (UTC) (envelope-from zlei@FreeBSD.org) From: Zhenlei Huang Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 (Mac OS X Mail 16.0 \(3696.120.41.1.8\)) Subject: gcc behavior of init priority of .ctors and .dtors section Message-Id: <3ECF8C28-D2D9-4212-B025-3EC64E46BADC@FreeBSD.org> Date: Thu, 16 May 2024 20:06:46 +0800 To: FreeBSD Current X-Mailer: Apple Mail (2.3696.120.41.1.8) 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. 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. Best regards, Zhenlei