[Bug ld/15685] New: R_X86_64_DTPOFF64 incorrectly handled
http://sourceware.org/bugzilla/show_bug.cgi?id=15685 Bug ID: 15685 Summary: R_X86_64_DTPOFF64 incorrectly handled Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: dblaikie at gmail dot com Given the following simpl.s: .file "simpl.c" .globl thrd .section.tdata,"awT",@progbits .align 4 .type thrd, @object .size thrd, 4 thrd: .long 2 .text .globl func .type func, @function func: .byte 0x42 .quad thrd@dtpoff .byte 0x42 .long thrd@dtpoff .byte 0x42 Assembled with gas and then linked with gold produces: 0e0 0004 fc42 0f0 42ff fffc 0042 0002 0004 ie: fffc fffc Whereas with binutils-ld: 0e0 0004 f842 6000 0f0 4200 fffc 0042 0002 2e00 7973 ie: 006000f8 fffc -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/15685] R_X86_64_DTPOFF64 incorrectly handled
http://sourceware.org/bugzilla/show_bug.cgi?id=15685 David Blaikie changed: What|Removed |Added Version|unspecified |2.22 --- Comment #1 from David Blaikie --- (this came up while implementing TLS debug info in Clang - it's possible that TLS support in Clang will use this relocation & thus be broken when using binutils-ld to link) -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/15685] R_X86_64_DTPOFF64 incorrectly handled
http://sourceware.org/bugzilla/show_bug.cgi?id=15685 --- Comment #2 from David Blaikie --- & I guess http://sourceware.org/ml/binutils/2002-09/msg00601.html might be relevant (mentions that this wasn't implemented way back in 2002, perhaps it's still just as unimplemented) -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/15685] R_X86_64_DTPOFF64 incorrectly handled
http://sourceware.org/bugzilla/show_bug.cgi?id=15685 David Blaikie changed: What|Removed |Added CC||echristo at gmail dot com --- Comment #5 from David Blaikie --- Apologies for the problematic reproduction - just trying to reduce this & accidentally dropped the debug_info section. Of course it does reproduce from within the debug_info section as well. (In reply to H.J. Lu from comment #4) > Created attachment 7098 [details] > A patch > > Please try this. This patch works for me - once I fix a bug in LLVM regarding these very same relocations (for some reason Clang was assembling these as "R_X86_64_64 tls" instead of "R_X86_64_DTPOFF64 tls" yet Gold was somehow OK with that & seemed to give the right answer) -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/21894] New: gdb-index fails to parse debug_ranges base address specifiers in 32 bit address files
https://sourceware.org/bugzilla/show_bug.cgi?id=21894
Bug ID: 21894
Summary: gdb-index fails to parse debug_ranges base address
specifiers in 32 bit address files
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: dblaikie at gmail dot com
CC: ian at airs dot com
Target Milestone: ---
LLVM recently gained support for using DWARF debug_range base address
specifiers to reduce relocations.
This broke Chromium builds using gold's gdb-index in a 32 bit build.
https://bugs.llvm.org/show_bug.cgi?id=34007
Looks like this is a bug in gold's parsing of debug_range. From the last
comment in the above bug:
"Yep, gold bug in parsing 32 bit range lists. The value in the table is read as
32 bit unsigned, widened to long, then compared to -1."
"Here's a dodgy change but at least demonstrates that gold seems to work fine
with this issue addressed:
---
../.citc/baseline/google3/third_party/binutils/binutils/gold/dwarf_reader.cc
2017-06-22 19:38:27.0 -0700
+++ third_party/binutils/binutils/gold/dwarf_reader.cc 2017-07-31
16:48:58.0 -0700
@@ -442,12 +442,12 @@
break;
// A "base address selection entry" is identified by
// 0x for the first value of the pair. The second
// value is used as a base for subsequent range list entries.
- if (shndx1 == 0 && start == -1)
- base = end;
+ if (shndx1 == 0 && start == (addr_size == 4 ? 4294967295 : -1))
+base = end;
else if (shndx1 == shndx2)
{
if (shndx1 == 0 || object->is_section_included(shndx1))
ranges->add(shndx1, base + start, base + end);
}
A little above in the code the 'start' value is read as an unsigned 4 byte int,
widened into an signed 8 byte int, which doesn't sign extend (since it wasn't
signed)."
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/29529] [objdump] -l flag can't parse -gdwarf-5 file name info from clang
https://sourceware.org/bugzilla/show_bug.cgi?id=29529 --- Comment #1 from David Blaikie --- So DWARFv5 added a zeroth entry to the line table (used to be the line table started at 1). GCC produces two entries even for a simple file - a zeroth and a first, both with the same value, and GCC always use the first. Clang produces one entry and uses that. Looks like objdump is ignoring/marking the zeroth as "unknown" - if you add a #line to the source so that Clang uses that as a first entry (after the zeroth original entry) then objdump behaves fine. So, yeah, missing zeroth entry in DWARFv5 (now that it has zeroth entries) somewhere in objdump. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/29641] gold, dwp: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29641 David Blaikie changed: What|Removed |Added CC||dblaikie at gmail dot com --- Comment #1 from David Blaikie --- Presumably some of this comes for free from common binutils infrastructure, like was the case for gdb, maybe? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/23310] Support DWARF-5 line table features in assembler
https://sourceware.org/bugzilla/show_bug.cgi?id=23310 David Blaikie changed: What|Removed |Added CC||dblaikie at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/25614] dwarf-5 allows for .file 0
https://sourceware.org/bugzilla/show_bug.cgi?id=25614 David Blaikie changed: What|Removed |Added CC||dblaikie at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25614] dwarf-5 allows for .file 0
https://sourceware.org/bugzilla/show_bug.cgi?id=25614 --- Comment #12 from David Blaikie --- (In reply to Nick Clifton from comment #11) > Hi Nick, > > Right - I have now checked in a patch which should provide full support for > the ".file 0" directive. Plus it handles .file "dir" "file" md5 as > well. > > One question - what is the .addrsig directive ? It is in the foo.s file > that you uploaded (near the end) but gas does not recognise it. Here's the documentation for the addrsig LLVM extension: https://llvm.org/docs/Extensions.html#sht-llvm-addrsig-section-address-significance-table -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25614] dwarf-5 allows for .file 0
https://sourceware.org/bugzilla/show_bug.cgi?id=25614 --- Comment #14 from David Blaikie --- (In reply to Nick Clifton from comment #13) > (In reply to David Blaikie from comment #12) > Hi David, > > > > One question - what is the .addrsig directive ? It is in the foo.s file > > > that you uploaded (near the end) but gas does not recognise it. > > > > Here's the documentation for the addrsig LLVM extension: > > https://llvm.org/docs/Extensions.html#sht-llvm-addrsig-section-address- > > significance-table > > Thanks for the reference. This is obviously a new feature, so it will > need a new PR being filed. Ideally of course someone from the LLVM > community will offer a patch to add the feature, but if that does not > happen then I will put it on my (long) list of things to do. > > Cheers > Nick *nod* seems unlikely it'd be a high priority for participants either project, unless GCC folks find the feature itself to be valuable, want to implement it in gold/binutils ld, etc. Arguably LLVM/Clang could probably use a mode (& probably should be the default behavior for -fno-integrated-as, though overridable) that produces binutils as-compatible assembly & skip features like this. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25614] dwarf-5 allows for .file 0
https://sourceware.org/bugzilla/show_bug.cgi?id=25614
--- Comment #16 from David Blaikie ---
(In reply to cvs-com...@gcc.gnu.org from comment #15)
> The master branch has been updated by Maciej W. Rozycki
> :
>
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;
> h=876678f05e70235ed71d5b9ec63e4f6db1ec76e4
>
> commit 876678f05e70235ed71d5b9ec63e4f6db1ec76e4
> Author: Maciej W. Rozycki
> Date: Tue Mar 31 23:01:36 2020 +0100
>
> PR 25611, PR 25614: GAS: Remove a double inclusion of "bignum.h"
>
> Correct an issue with commit 5496f3c635dc ("Add support for generating
> DWARF-5 format directory and file name tables from the assembler.") and
> remove a duplicate direct inclusion of "bignum.h" from dwarf2dbg.c that
> causes a GAS compilation error:
>
> In file included from .../gas/dwarf2dbg.c:33:
> .../gas/bignum.h:42: error: redefinition of typedef 'LITTLENUM_TYPE'
> .../gas/bignum.h:42: error: previous declaration of 'LITTLENUM_TYPE' was
> here
> make[4]: *** [dwarf2dbg.o] Error 1
>
> with some GCC versions, as this header has been already included via
> "as.h" and then "flonum.h".
>
> gas/
> PR 25611
> PR 25614
> * dwarf2dbg.c: Do not include "bignum.h".
bignum.h seems brittle - I guess there's a reason it doesn't have include
guards? (if it doesn't have include guards, perhaps it shouldn't be included
from other headers? Maybe given a different extension?)
--
You are receiving this mail because:
You are on the CC list for the bug.
