bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VtwzW71CMz47q1; Tue, 4 Jun 2024 16:29:43 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1717518584; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JBIVnJ6nb6vRjwjhEGQNMQGgCDcGXXslBJnHPRDlJzY=; b=t9v9UVDWyGti+lQebCc+Ff6R4lPcq+aY0lcWnDTE/Om8EfjdxrKkBmNim9NbgTxUMHDmE2 v2wpRfnhzVCI6uac6N1reRGvUlQnZ/G0VfiTttEgM4UqqauYsVeyGRlTOFLiR395T8czuA z7uqMLYRrKqHsriX6atKe0dWd1bQDCEZMB+wpVaIg3BlUgYccW4XHe0LGXfYgsUy5R2AoD OsMFRhCKZyj3K9CeClLbd401m2d1h5v1ez5DUMbwgFG+/kD0292/YO62dz1tHqxVhEmb7n 5J8iVxBZvhefb0n8ryTa8Esq7DRUXDuuCaoBZJLxPpQPDbH9t8Ag6N1u9y1L0w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1717518584; a=rsa-sha256; cv=none; b=FAgQ80j2TsyPFYWhWCLGLSmRPEAn8Bt9IVwREauNPYJQQnIxTwZyPes4pBs4lYTBSnj9gK 8JyFSdJDKPKST3uCDkvwOLp6XxOFheveZeSX6j9w/lKWceSYxKUbJNNvjK1TbkI7cheC95 WuzHfJZt6Q8Ulz8WfY4/5EQmYXeN3zT0xURTCyI26/C2Nsu74bD/pckwu681e5qO0hDnFg 2mjsuzy32CfDRRXIVAgk78BrSAHXcuVqLu8VUUJUjRVVrpjKdZnSVHF3nkmIxd6ODjv0Lv se3qCieYq1R7jrhh3N96NhGQTZal0y9t7IsE/towEC9IuEcqDV0KhYifoPq5HQ== 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=1717518584; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JBIVnJ6nb6vRjwjhEGQNMQGgCDcGXXslBJnHPRDlJzY=; b=xcbpUOBGpfhcJ8IKOZJRMIsytEFOfffSZAsnixf49SXYm0C3mN2t7s8V0m0/Kn72CNaUsA Aqdrc1IO+SPeodm6o96ZEhHOHBRNJBUwgPgpG1jxX3kqy4vE+3qMA30IbNfvIN4ZqlmTH4 zME3SUL3x/NnM21k47PrBEj8AlcVH7eEkiEon5XaQ/gL82fQh8tWIbTmdtFCaQ51ApLLI4 wdYLiW80UGKKboRsoj4vLJ3iwpo+8NNP6NIxU/jzwpOpLt75K9Mlkp1geD04KH/PuoUx4A W2vIicEOFYXMelmUQZzW0GuOVy1LEK+GoBKFWA+KUcgB9x2TyC8qtFpO5ZT7hg== Received: from [IPV6:2601:644:937f:4c50:e0fb:ab3b:bf07:f04] (unknown [IPv6:2601:644:937f:4c50:e0fb:ab3b:bf07:f04]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4VtwzW3LVgzFny; Tue, 4 Jun 2024 16:29:43 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Tue, 4 Jun 2024 09:29:41 -0700 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 User-Agent: Mozilla Thunderbird Subject: Re: gcc behavior of init priority of .ctors and .dtors section Content-Language: en-US To: Lorenzo Salvadore , Konstantin Belousov Cc: Zhenlei Huang , FreeBSD Current References: <3ECF8C28-D2D9-4212-B025-3EC64E46BADC@FreeBSD.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/16/24 4:05 PM, Lorenzo Salvadore wrote: > 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` >>> >>> 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. > > If this is indeed the issue, switching to a -devel GCC port should fix it. FWIW, the devel/freebsd-gcc* ports have passed this flag to GCC's configure for a long time (since we made the switch in clang). -- John Baldwin