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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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: W
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
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
Jakub Jelinek changed:
What|Removed |Added
Attachment #50460|0 |1
is obsolete|
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_se
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.
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|
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.
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
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 us
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_l
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
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
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 W
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.
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 wou
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
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?
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
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/sho
23 matches
Mail list logo
