[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #38 from Mikael Pettersson --- After updating binutils to ba6eb62ff0ea9843a018cfd7cd06777bd66ae0a0, including the fix for BZ 27268, I was able to do a full bootstrap of current gcc head on Cygwin64. https://sourceware.org/bugzilla/show_bug.cgi?id=27268 has more detail.
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #39 from Jakub Jelinek --- Ok, so what do we want to do on the gcc side? Nothing, just tell users they need latest binutils? Or try to add a configure check to detect broken binutils that doesn't handle the DWARF5 new sections and if it detects broken binutils, in ix86_option_override_internal if (TARGET_PECOFF && dwarf_version > 4) and #ifdef the new macro about broken pecoff binutils set dwarf_version to 4 (if !global_options_set.x_dwarf_version silently, otherwise with a warning (but perhaps just once per the whole TU))? As I have no access to Windows, I'm afraid I can't easily write a configure test myself, I can help with the i386-options.c change if needed, but can't test anything.
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #40 from jyong at gcc dot gnu.org --- Personally I'm fine with gcc configure warning of a potentially broken binutils dwarf5 handing when targeting mingw/cygwin with binutils 2.35.1 or earlier. How do you even parse binutils versions? Of course, all bets are off if build!=host.
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #41 from Jakub Jelinek --- gcc/configure has e.g. $ld_vers_major and $ld_vers_minor and $ld_vers_patch. But as the fix was March 1st, I think it is neither in 2.35.2 nor in 2.36. I think a feature test would be better, try to assemble as short assembly as possible with the new DWARF5 sections in it (with the actual code perhaps replaced just by a nop), link it and look at it using objdump if the sections are right or not?
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #42 from Jakub Jelinek ---
As a start, perhaps compiling
void
foo (void)
{
int a = 1;
asm ("nop");
a = 2;
asm ("nop");
a = 3;
}
with -gdwarf-5 -O2 -dA to get the assembly. But bet it can be reduced manually
somewhat, it would e.g. just drop the function altogether and in .debug_info
have just DW_TAG_compile_unit DIE with its attributes and drop
DW_TAG_subprogram etc., and only have DW_AT_ranges on it that points to minimal
.debug_rnglists.
Or keep the DW_TAG_subprogram in there but just say the ranges and nothing else
for it.
But if it needs to cover both 64-bit and 32-bit assembly for PE, either you
need two sets of assembly in the configure or tweak it by hand.
You can have a look e.g. at what the HAVE_AS_WORKING_DWARF_N_FLAG testing uses
as assembly as an example.
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #43 from jyong at gcc dot gnu.org ---
Is it as simple as running the following?
${target}-objdump -j .debug_loclists -h a.exe | grep -q 0001
A return code 0 means potentially broken linker script is used.
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #44 from Jakub Jelinek --- Yes. Or maybe instead check that objdump -j .debug_loclists -h (or .debug_rnglists) has both VMA and LMA all zeros instead? Dunno what exactly that command prints in broken and what on correct binaries on Windows (when using DWARF5).
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #45 from Jakub Jelinek ---
I have tried the mingw gcc/binutils crosses we have in Fedora (gcc 10.2.1) and
get:
i686-w64-mingw32-objdump -h ./pr98860.exe
./pr98860.exe: file format pei-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .debug_loclists 002a 0448 2**0
CONTENTS, READONLY, DEBUGGING
1 .debug_rnglists 0013 0648 2**0
CONTENTS, READONLY, DEBUGGING
2 .text 17d4 00401000 00401000 0a00 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
3 .data 0034 00403000 00403000 2200 2**2
CONTENTS, ALLOC, LOAD, DATA
4 .rdata08ec 00404000 00404000 2400 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .eh_frame 08d0 00405000 00405000 2e00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .bss 0408 00406000 00406000 2**5
ALLOC
7 .idata0588 00407000 00407000 3800 2**2
CONTENTS, ALLOC, LOAD, DATA
8 .CRT 0034 00408000 00408000 3e00 2**2
CONTENTS, ALLOC, LOAD, DATA
9 .tls 0008 00409000 00409000 4000 2**2
CONTENTS, ALLOC, LOAD, DATA
10 .debug_aranges 0078 0040a000 0040a000 4200 2**3
CONTENTS, READONLY, DEBUGGING
11 .debug_info 3530 0040b000 0040b000 4400 2**0
CONTENTS, READONLY, DEBUGGING
12 .debug_abbrev 063e 0040f000 0040f000 7a00 2**0
CONTENTS, READONLY, DEBUGGING
13 .debug_line 0795 0041 0041 8200 2**0
CONTENTS, READONLY, DEBUGGING
14 .debug_frame 0038 00411000 00411000 8a00 2**2
CONTENTS, READONLY, DEBUGGING
15 .debug_str0360 00412000 00412000 8c00 2**0
CONTENTS, READONLY, DEBUGGING
16 .debug_loc039d 00413000 00413000 9000 2**0
CONTENTS, READONLY, DEBUGGING
17 .debug_ranges 00d8 00414000 00414000 9400 2**0
CONTENTS, READONLY, DEBUGGING
so in that case it seems that .debug_{loclists,rnglists} etc. should use
non-zero VMA/LMA like other debug sections rather than zero like they currently
do.
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #46 from jyong at gcc dot gnu.org --- Is there a machine parsable output from objdump? I'm not sure if using gawk would be OK. Such a test also won't work in build != host conditions. I'm considering just having a notice in the gcc-11 release note to the particular binutils commit/patch, so that anyone rolling their own toolchain would be aware of it and try to apply the patch on binutils, since no released version has the patch yet.
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #47 from Jakub Jelinek --- Does mingw/cygwin always use GNU binutils? At least for ld.bfd, a quick and reliable test could be $gcc_cv_ld --verbose 2>&1 | grep -q '\.debug_loclists.*BLOCK.*__section_alignment__.*NOLOAD.*:' && $gcc_cv_ld --verbose 2>&1 | grep -q '\.debug_rnglists.*BLOCK.*__section_alignment__.*NOLOAD.*:' or so in configure.ac (for mingw/cygwin only, and AC_DEFINE a macro in that case).
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #48 from jyong at gcc dot gnu.org --- Now that's an interesting trick I never thought of. There's LLVM based mingw, but I have never used nor do I know if it is relevant here. Gold is ELF only as far as I know, so it would never be used. That should leave only BFD ld.
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #49 from Jakub Jelinek --- Created attachment 50459 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50459&action=edit gcc11-pr98860.patch In that case this completely untested patch which could work, but no way to really test it myself properly (nor have time to do that). It needs testing both with bad and good binutils.
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #50 from jyong at gcc dot gnu.org --- I'll try testing it out over the next few days, thanks for the patch.
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 jyong at gcc dot gnu.org changed: What|Removed |Added Attachment #50459|0 |1 is obsolete|| --- Comment #51 from jyong at gcc dot gnu.org --- Created attachment 50460 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50460&action=edit Slightly adjusted patch to fix errors Adjust the patch to deal with xyes and silent result issues. Testing with older binutils worked, -gdwarf-5 ignored, not sure if intentional.
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #52 from jyong at gcc dot gnu.org --- Oops I need retest with optimizations enabled to see the debug sections emitted. On the other hand, the new adjusted patch detects the binutils bug fine, tested with new and old binutils.
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #53 from Jakub Jelinek --- Comment on attachment 50460 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50460 Slightly adjusted patch to fix errors Thanks for fixing my bugs, but there is another one: if (TARGET_PECOFF && opts_set->x_dwarf_version) should have been really if (TARGET_PECOFF && !opts_set->x_dwarf_version) The intent was to make -gdwarf-4 the default for broken linker, but still support -gdwarf-5 in the hope that when using it explictly, the user has updated his linker. Another option is to issue a warning or inform for the #ifdef HAVE_LD_BROKEN_PE_DWARF5 if (TARGET_PECOFF && opts_set->x_dwarf_version && opts->x_dwarf_version >= 5) case and reset it to -gdwarf-4.
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 Jakub Jelinek changed: What|Removed |Added Attachment #50460|0 |1 is obsolete|| --- Comment #54 from Jakub Jelinek --- Created attachment 50461 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50461&action=edit gcc11-pr98860.patch So the non-noisy version of the patch could be this.
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #55 from Jakub Jelinek --- Created attachment 50462 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50462&action=edit gcc11-pr98860-2.patch And the noisy variant this.
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #56 from jyong at gcc dot gnu.org --- OK, I've tested the patch from attachment 50461, seems to work fine: gcc uses dwarf 4 by default if it does find a broken linker, but allows the user to specify -gdwarf-5 if they want, resulting in a broken executable. If the linker was found to be working at build time, dwarf-5 would be default. I prefer the non-noisy patch because gcc doesn't actually detect the linker bug at runtime, just silently doing what it thinks is best, which may not be accurate if the user upgrades or downgrades binutils without a rebuild.
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #57 from Roger Orr --- I've also confirmed the "non-noisy" patch when used with binutils 2.35.2 (Sadly I've not yet manged to build binutils from source to try dwarf-5 with the fix) Many thanks. I believe the "noisy" patch needs an edit in the line: @@ -1861,6 +1861,15 @@ ix86_option_override_internal (bool main which should be @@ -1861,6 +1861,21 @@ ix86_option_override_internal (bool main (at least, I can't apply it without that change...)
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #58 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a49a96f681bf13c6e77644d4507e867f00f93fe6 commit r11-7923-ga49a96f681bf13c6e77644d4507e867f00f93fe6 Author: Jakub Jelinek Date: Wed Mar 31 09:11:29 2021 +0200 i386, debug: Default to -gdwarf-4 on Windows targets with broken ld.bfd [PR98860] As mentioned in the PR, before the https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba6eb62ff0ea9843a018cfd7cd06777bd66ae0a0 fix from March 1st, PECOFF ld.bfd didn't know about .debug_loclists, .debug_rnglists and other debug sections new in DWARF 5. Unfortunately, unlike for ELF linkers, that means the sections were placed in wrong ordering with wrong VMA/LMA, so the resulting executables are apparently unusable. As that is pretty new change, newer than 2.35.2 or 2.36 binutils releases, the following patch adds a workaround that turns -gdwarf-4 by default instead of -gdwarf-5 if a broken linker is found at configure time. Users can still explicitly play with -gdwarf-5 and either use a non-broken linker or use custom linker scripts for the broken one, but at least by default it should work. 2021-03-31 Jakub Jelinek PR bootstrap/98860 * configure.ac (HAVE_LD_BROKEN_PE_DWARF5): New AC_DEFINE if PECOFF linker doesn't support DWARF sections new in DWARF5. * config/i386/i386-options.c (ix86_option_override_internal): Default to dwarf_version 4 if HAVE_LD_BROKEN_PE_DWARF5 for TARGET_PECOFF targets. * config.in: Regenerated. * configure: Regenerated.
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #59 from Jakub Jelinek --- The non-noisy workaround applied.
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #60 from jyong at gcc dot gnu.org --- Thanks all for debugging and finding a solution.
