From nobody Thu May 16 20:05:57 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 4VgLgz0wGbz5K5hZ for ; Thu, 16 May 2024 20:06:07 +0000 (UTC) (envelope-from developer@lorenzosalvadore.it) Received: from mail-4317.proton.ch (mail-4317.proton.ch [185.70.43.17]) (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 "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VgLgy5p6Bz4nxX for ; Thu, 16 May 2024 20:06:06 +0000 (UTC) (envelope-from developer@lorenzosalvadore.it) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lorenzosalvadore.it; s=protonmail; t=1715889964; x=1716149164; bh=xNo7M8FY8ueTdpupSiLQPFzNybuGxcb5NAbpCQK1PzQ=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=GFMXm7wNO2M09LmGelbvN8PFX3RlX2+PQBMWpeeRkI/6LOsQd/uIxqe41UFxCCc/0 37ybhdSHXw7LxJ37S2PR5ox533+W0dovZOCScdjHrImilxILgEZYJPEfjN9iFw4wMV 3GwhFNpFT0oIjfIAI7AzKs+Q9T1KnSoONYg+FGFCehuYqbWFqBCEqX0TXfK90Ml4cq /tOQ97tCFQL7Dqy5zqwWxOV35Wz3PvH8gwIOVx2UyHsjVUiY84/6eQ4QeEuqqzkmO2 fc19kSHka0H5BIAQ3r/pRfhF5W6xjTclRA7yMj7jd8WHkUc0CsJ6EME05iRnJVSTvR xblvhQqyCVx7A== Date: Thu, 16 May 2024 20:05:57 +0000 To: Konstantin Belousov From: Lorenzo Salvadore Cc: Zhenlei Huang , FreeBSD Current Subject: Re: gcc behavior of init priority of .ctors and .dtors section Message-ID: In-Reply-To: References: <3ECF8C28-D2D9-4212-B025-3EC64E46BADC@FreeBSD.org> Feedback-ID: 53711648:user:proton X-Pm-Message-ID: f896ed76f9cbc6da4d10a6449c7bc6d32ab280d8 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=utf-8 Content-Transfer-Encoding: quoted-printable 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:62371, ipnet:185.70.43.0/24, country:CH] X-Rspamd-Queue-Id: 4VgLgy5p6Bz4nxX On Thursday, May 16th, 2024 at 20:26, Konstantin Belousov 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` > >=20 > > The above order is not expected. I think clang's one is correct. > >=20 > > Further hacking with readelf shows that clang produces the right order = of > > section .rela.ctors but gcc does not. > >=20 > > ``` > > # clang -fno-use-init-array -c ctors.c && readelf -r ctors.o | grep 'Re= location 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 > > --- > >=20 > > > 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 > > > ``` > >=20 > > The above show clearly gcc produces the wrong order of section `.rela.c= tors`. > >=20 > > Is that expected behavior ? > >=20 > > I have not tried Linux version of gcc. >=20 > Note that init array vs. init function behavior is encoded by a note adde= d > 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 p= orts 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 soo= n to be added to the ports tree and will have it since the beginning. If this is indeed the issue, switching to a -devel GCC port should fix it. Cheers, Lorenzo Salvadore