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
Content-Language: en-US
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>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
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.