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 tono 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"
After switching to make 4.1r2, the build worked beautifully.
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
On Monday, November 1, 2021 at 10:21:03 AM UTC+1, Stefan Ring wrote:to no avail. The same thing happened there.
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
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
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
have not tested this.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
After switching to make 4.1r2, the build worked beautifully.
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)
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).
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"), \
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 463 |
Nodes: | 16 (2 / 14) |
Uptime: | 154:54:15 |
Calls: | 9,383 |
Calls today: | 3 |
Files: | 13,561 |
Messages: | 6,095,746 |