While trying to recreate the DJGPP gcc binaries, by following the excellent instructions in readme.DJGPP, I stumbled across this problem that caused me a lot of grief. I used Windows XP for building and even installed Vista as a possible remedy, but to no avail. The same thing happened there.

The last line in libgcc/Makefile.in does an include of *.dep, but somehow in make 4.3 the expansion of this wildcard expression gets truncated somewhere in the middle, and then it complains about not being able to find the file whose name got truncated. I patched around this by splitting it up into multiple chunks of wildcard matches on multiple lines, but this got me further only by a tiny amount. The next problem was that during an "exit 0" in the configuration stage, make would say "memory fouled" and abort.

After switching to make 4.1r2, the build worked beautifully.

On Monday, November 1, 2021 at 10:21:03 AM UTC+1, Stefan Ring wrote:
> While trying to recreate the DJGPP gcc binaries, by following the excellent instructions in readme.DJGPP, I stumbled across this problem that caused me a lot of grief. I used Windows XP for building and even installed Vista as a possible remedy, but to no avail. The same thing happened there.
>
> The last line in libgcc/Makefile.in does an include of *.dep, but somehow in make 4.3 the expansion of this wildcard expression gets truncated somewhere in the middle, and then it complains about not being able to find the file whose name got truncated. I patched around this by splitting it up into multiple chunks of wildcard matches on multiple lines, but this got me further only by a tiny amount. The next problem was that during an "exit 0" in the configuration stage, make would say "memory fouled" and abort.
>
> After switching to make 4.1r2, the build worked beautifully.

I forgot to mention: I used Andris Pavenis' builds from the directory "rpms/djcross-gcc-10.3.0" to create gcc1030s.zip and this in turn for building on Windows. And I consider it very likely that at least 10.2.0 will be affected in the same way, but I have not tested this.

On 11/1/21 11:48, Stefan Ring (stefanrin@gmail.com) [via djgpp@delorie.com] wrote:
> On Monday, November 1, 2021 at 10:21:03 AM UTC+1, Stefan Ring wrote:
>> While trying to recreate the DJGPP gcc binaries, by following the excellent instructions in readme.DJGPP, I stumbled across this problem that caused me a lot of grief. I used Windows XP for building and even installed Vista as a possible remedy, but to no avail. The same thing happened there.
>>
>> The last line in libgcc/Makefile.in does an include of *.dep, but somehow in make 4.3 the expansion of this wildcard expression gets truncated somewhere in the middle, and then it complains about not being able to find the file whose name got truncated. I patched around this by splitting it up into multiple chunks of wildcard matches on multiple lines, but this got me further only by a tiny amount. The next problem was that during an "exit 0" in the configuration stage, make would say "memory fouled" and abort.
>>
>> After switching to make 4.1r2, the build worked beautifully.
> I forgot to mention: I used Andris Pavenis' builds from the directory "rpms/djcross-gcc-10.3.0" to create gcc1030s.zip and this in turn for building on Windows. And I consider it very likely that at least 10.2.0 will be affected in the same way, but I have not tested this.
>
Actually gcc-10.3.0 was built for DJGPP, just not uploaded (both RPMs and DJGPP packages).
Uploading could be easy.

gcc-11 is a different story:

- Ada library does not compile - alignment issues which are likely to cause problems also for other
languages like (c or C++) when SSE or AVX is being used (and maybe even with earlier GCC versions)

- I have build gcc-11 cross-compiler under ArchLinux (leaving Ada out). There was some problems
building RPM but I have not studied them in more details

- Also building native compiler failed (also without Ada)

Problem with cross-compiler:

- libstdc++v3 configure does not check correctly available C library functions and as result they
may not be put into std namespace. I would like to do cross-native build (building DJGPP native
compiler using cross-compiler from Linux but it would have the same problem with libstdc++

Also:

Actually myös SRPM package is generated. Generating script is not in SRPM or gccXXXs.zip but can be
found in my GCC repo fork in GitHub.

For djgpp/native/gcc-10 branch it is:

https://github.com/apavenis/djgpp-gcc/blob/djgpp/native/gcc-10/djgpp/mk-djcross-gcc.sh

Script generates

- SRPM package

- patch to be applied for ArchLinux build

Andris

On Wednesday, November 3, 2021 at 3:43:44 PM UTC+1, Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.com] wrote:
> Actually gcc-10.3.0 was built for DJGPP, just not uploaded (both RPMs and DJGPP packages).
> Uploading could be easy.
>
> Problem with cross-compiler:
>
> - libstdc++v3 configure does not check correctly available C library functions and as result they
> may not be put into std namespace. I would like to do cross-native build (building DJGPP native
> compiler using cross-compiler from Linux but it would have the same problem with libstdc++
>
> Also:
>
> Actually myös SRPM package is generated. Generating script is not in SRPM or gccXXXs.zip but can be
> found in my GCC repo fork in GitHub.
>
> For djgpp/native/gcc-10 branch it is:
>
> https://github.com/apavenis/djgpp-gcc/blob/djgpp/native/gcc-10/djgpp/mk-djcross-gcc.sh
>
> Script generates
>
> - SRPM package
>
> - patch to be applied for ArchLinux build

Yeah, I figured out most of this, and I already used the SRPM to build the zip and build that on Windows. I just noticed that it does not work with (djgpp) make 4.3, but it does with make 4.1r2 (from the directory "deleted", IIRC).

I also did a cross-native build of gcc-10.3, and it seemed to work ok, but I did not test it on anything more sophisticated than a C++ "Hello World".

Another user have problem with Make 4.3 when compiling Mplayer for DOS:
http://www.bttr-software.de/forum/forum_entry.php?id=18363

H:\DJGPP\BUILD\MPLAYER\MPLAYER>make
Exiting due to signal SIGSEGV
Page fault at eip=0002b22e, error=0004
eax=00000001 ebx=00000030 ecx=000fec10 edx=000febe0 esi=000d9578 edi=00000000
ebp=000d9558 esp=000d9550 program=H:\DJGPP\BIN\MAKE.EXE
cs: sel=00a7 base=00400000 limit=0011ffff
ds: sel=00af base=00400000 limit=0011ffff
es: sel=00af base=00400000 limit=0011ffff
fs: sel=008f base=00018190 limit=0000ffff
gs: sel=00bf base=00000000 limit=0010ffff
ss: sel=00af base=00400000 limit=0011ffff
App stack: [000daa50..0005aa50] Exceptn stack: [0005a96c..00058a2c]

Neither increasing of transfer buffer in stub didn't help.

On 2021-11-03 15:43, Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.com] wrote:
> Actually gcc-10.3.0 was built for DJGPP, just not uploaded (both RPMs and DJGPP packages). Uploading could be easy.

I've been waiting for djcross-gcc-10.3.0.tar.bz2, please do upload :)

> gcc-11 is a different story:
>
> - Ada library does not compile - alignment issues which are likely to cause problems also for other languages like (c or C++) when SSE or AVX is being used (and maybe even with earlier GCC versions)

What sort of alignment issues? I already ran into alignment trouble with SSE
(at run-time, not compile-time). To work around it, in the linker script I put
SUBALIGN(0x10) on the .text and .bss sections. For .data this is not possible
because it leaves gaps in the ctors/dtors list, so I ended up linking
*(.data .data.* .gnu.linkonce.d*) in .text. A bit of a hack but .text is
writable. I suppose the input section alignment could be changed in binutils
somewhere though.

Also in libc I had to put attribute __attribute__((force_align_arg_pointer)) on
__crt1_startup() to align the stack for ctors & main(). Alternatively this
alignment could be performed manually in crt0.S.

On 11/8/21 11:53, J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com] wrote:
> On 2021-11-03 15:43, Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.com] wrote:
>> Actually gcc-10.3.0 was built for DJGPP, just not uploaded (both RPMs and DJGPP packages).
>> Uploading could be easy.
>
> I've been waiting for djcross-gcc-10.3.0.tar.bz2, please do upload :)

File was already inside SRPM file so it was available. Just download size was big, Extracted and
uploaded

>
>> gcc-11 is a different story:
>>
>> - Ada library does not compile - alignment issues which are likely to cause problems also for
>> other languages like (c or C++) when SSE or AVX is being used (and maybe even with earlier GCC
>> versions)
>
> What sort of alignment issues?  I already ran into alignment trouble with SSE
> (at run-time, not compile-time).  To work around it, in the linker script I put
> SUBALIGN(0x10) on the .text and .bss sections.  For .data this is not possible
> because it leaves gaps in the ctors/dtors list, so I ended up linking
> *(.data .data.* .gnu.linkonce.d*) in .text.  A bit of a hack but .text is
> writable.  I suppose the input section alignment could be changed in binutils
> somewhere though.
>
> Also in libc I had to put attribute __attribute__((force_align_arg_pointer)) on
> __crt1_startup() to align the stack for ctors & main(). Alternatively this
> alignment could be performed manually in crt0.S.

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).

Andris

On 2021-11-09 17:43, Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.com] wrote:
> On 11/8/21 11:53, J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com] wrote:
>> On 2021-11-03 15:43, Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.com] wrote:
>>> Actually gcc-10.3.0 was built for DJGPP, just not uploaded (both RPMs and DJGPP packages). Uploading could be easy.
>>
>> I've been waiting for djcross-gcc-10.3.0.tar.bz2, please do upload :)
>
>
> File was already inside SRPM file so it was available. Just download size was big, Extracted and uploaded

Thanks!

>>
>>> gcc-11 is a different story:
>>>
>>> - Ada library does not compile - alignment issues which are likely to cause problems also for other languages like (c or C++) when SSE or AVX is being used (and maybe even with earlier GCC versions)
>>
>> What sort of alignment issues?  I already ran into alignment trouble with SSE
>> (at run-time, not compile-time).  To work around it, in the linker script I put
>> SUBALIGN(0x10) on the .text and .bss sections.  For .data this is not possible
>> because it leaves gaps in the ctors/dtors list, so I ended up linking
>> *(.data .data.* .gnu.linkonce.d*) in .text.  A bit of a hack but .text is
>> writable.  I suppose the input section alignment could be changed in binutils
>> somewhere though.
>>
>> Also in libc I had to put attribute __attribute__((force_align_arg_pointer)) on
>> __crt1_startup() to align the stack for ctors & main(). Alternatively this
>> alignment could be performed manually in crt0.S.
>
> 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"), \

On 2021-11-10 12:44, J.W. Jagersma wrote:
> On 2021-11-09 17:43, Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.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.