X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient:	djgpp AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20210112;
	h=message-id:date:mime-version:user-agent:subject:content-language
	:from:to:references:in-reply-to:content-transfer-encoding;
	bh=FNw4aa0mjdACu1QndH0u6hFOJBsQw3heDBgMO+HhuMs=;
	b=U848AZ66IUtswdPMdIgcDwAyiuV1yzrGBxt07ueuprNJ6gUH0Xr0g08IifMQuw0Bak
	emwMSydoPDMg++F2ymn9WUpFdzQEJPKyPyusQrZzRbErvPiw3vBvFGxOdJZj4tN3Pevj
	3rp/noJbXGnP9BVvlxVk5ZEKAWo4JuJtQ4MGy3sRW9OPr0Zk6pMvgzkg8AeqFmOyJDYL
	pUUN4+fLrRfBJldRV3t+QgZdCe4fUwK3Eg+aXBBpgcht00O3hP3Y0Jj91N/OiLx7N4Xw
	n/SwKMN8XOjjh5Juaqdcbl5tptdNpi+vvv9dr6guPpGsEQ8Ybib6LwOtfyEFXWY5rUTF
	hdTA==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20210112;
	h=x-gm-message-state:message-id:date:mime-version:user-agent:subject
	:content-language:from:to:references:in-reply-to
	:content-transfer-encoding;
	bh=FNw4aa0mjdACu1QndH0u6hFOJBsQw3heDBgMO+HhuMs=;
	b=UcfRXe2tFXY/Ts9LADoqA4OimqmZI9EGbrl1PFth7Ct4HayE3BKy69fSdIr8DZprs0
	7mdEIOP1Lj4TXSYwxwNUBGX/Ea2E1PdseCDTFImqjdZMjPdJ2dhvrF0rxIyj3XzjrLq2
	nW4QqyxE0iA93JnvXawHQjHn10xIiDf96VEG/FOEk/cXoq5MuLtzmItFLh6RO2IiAO8J
	YqevJxVNGCzwvRSJXTuuiX/yMJJuJCPzP7RkxofpEnm6uPnbW/Freu9q4vtyKpRRUAJ8
	WMvyp39cv9vCtQ+Q9vs4xxYWEI4X7yG2cTejNUR34iRrVXcAZBqdbPmAnYYqc1mCSW4s
	K2mA==
X-Gm-Message-State:	AOAM533OFYcWGeJfXSDpSb05SQWf6PW5LqmTWodtvtyv1Rh74h5SGjwP
	N4yFw3F57cQyZLJ17gfbEq/8LqPqxdA=
X-Google-Smtp-Source:	ABdhPJyKKaQRUg9wVszK39hqJcs6yfLpXJFlBoS0Dag7MIzOhwDDI/hpAHgoifuspsBQ+0Ks2PvodQ==
X-Received:	by 2002:a05:6402:2926:: with SMTP id ee38mr38184334edb.71.1637415628118;
	Sat, 20 Nov 2021 05:40:28 -0800 (PST)
Message-ID:	<ef96294f-7dbe-93c9-776c-dcf80b48d35e@gmail.com>
Date:	Sat, 20 Nov 2021 14:40:24 +0100
MIME-Version:	1.0
User-Agent:	Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101
	Thunderbird/91.3.1
Subject:	Re: DJGPP build of gcc-10.3.0 and make 4.3 incompatibility
From:	"J.W. Jagersma (jwjagersma AT gmail DOT com) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
To:	djgpp AT delorie DOT com
References:	<e69c2d84-e2cf-445c-b666-803170f473den AT googlegroups DOT com>
	<4016e9cd-0be1-4758-8f29-db7770508ed6n AT googlegroups DOT com>
	<df91c1b1-43f4-0074-dfd6-b271feb06b39 AT iki DOT fi>
	<9788a12e-c532-b273-a13d-ae12d2eed8a7 AT gmail DOT com>
	<2239fa27-8162-ac1c-d7ac-12bf7443493e AT iki DOT fi>
	<1d9e4c7e-baef-bf45-3a05-f28b426f2f37 AT gmail DOT com>
In-Reply-To:	<1d9e4c7e-baef-bf45-3a05-f28b426f2f37@gmail.com>
Reply-To:	djgpp AT delorie DOT com

On 2021-11-10 12:44, J.W. Jagersma wrote:
> On 2021-11-09 17:43, Andris Pavenis (andris DOT pavenis AT iki DOT fi) [via djgpp AT delorie DOT com] wrote:
>> I was thinking about possible runtime alignment problems.I have not tested it myself. Ada library has some alignment checks and as far as I understand refuses to compile as max. available alignment is not sufficient (error message is not clear).
> 
> I expect it would require 16-byte alignment as with SSE.  GCC has also used
> 16-byte default stack alignment for a while now, amd64 ABI also enforces this.
> I'm curious to know how the Ada compiler detects it though.
> 
> Currently in binutils only '.text' and '.data' are 16-byte aligned, as well as
> '.gnu.linkonce.{d,t,r}*', but not named sections such as '.text.unlikely', etc.
> If you compile with -ffunction-sections -fdata-sections then nothing will be
> aligned at all.
> Also '.bss*', '.gnu.linkonce.b*', '.const*' and '.rodata*' are only 4-byte
> aligned since there is no alignment entry defined for them.
> 
> Following patch should fix all this without ldscript hacks.  Stack alignment
> still needs to be done in libc of course, and I also noticed the ALIGN macro
> for malloc would need to be increased (nmalcdef.h:191).
> 
> (I don't know if the .const entry here is necessary, the linker script uses it
> but gcc only seems to produce .rodata...)
> 
> diff --git a/bfd/coff-go32.c b/bfd/coff-go32.c
> index d73c32b215d..3139ce07ac7 100644
> --- a/bfd/coff-go32.c
> +++ b/bfd/coff-go32.c
> @@ -28,9 +28,15 @@
>   #define COFF_LONG_FILENAMES
> 
>   #define COFF_SECTION_ALIGNMENT_ENTRIES \
> -{ COFF_SECTION_NAME_EXACT_MATCH (".data"), \
> +{ COFF_SECTION_NAME_PARTIAL_MATCH (".data"), \
>     COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMPTY, 4 }, \
> -{ COFF_SECTION_NAME_EXACT_MATCH (".text"), \
> +{ COFF_SECTION_NAME_PARTIAL_MATCH (".text"), \
> +  COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMPTY, 4 }, \
> +{ COFF_SECTION_NAME_PARTIAL_MATCH (".const"), \
> +  COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMPTY, 4 }, \
> +{ COFF_SECTION_NAME_PARTIAL_MATCH (".rodata"), \
> +  COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMPTY, 4 }, \
> +{ COFF_SECTION_NAME_PARTIAL_MATCH (".bss"), \
>     COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMPTY, 4 }, \
>   { COFF_SECTION_NAME_PARTIAL_MATCH (".gnu.linkonce.d"), \
>     COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMPTY, 4 }, \
> @@ -38,6 +44,8 @@
>     COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMPTY, 4 }, \
>   { COFF_SECTION_NAME_PARTIAL_MATCH (".gnu.linkonce.r"), \
>     COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMPTY, 4 }, \
> +{ COFF_SECTION_NAME_PARTIAL_MATCH (".gnu.linkonce.b"), \
> +  COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMPTY, 4 }, \
>   { COFF_SECTION_NAME_PARTIAL_MATCH (".debug"), \
>     COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMPTY, 0 }, \
>   { COFF_SECTION_NAME_PARTIAL_MATCH (".gnu.linkonce.wi"), \

Any objections if I submit this to binutils?  Even if it doesn't fix Ada, we
still need this for reliable SSE support.

- Raw text -