[Bug binutils/26829] New: [readelf] wrong dir printed for .dwo file listing

2020-11-02 Thread vries at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=26829

Bug ID: 26829
   Summary: [readelf] wrong dir printed for .dwo file listing
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider the source files gdb/testsuite/gdb.dwarf2/fission-multi-cu*.c,
compiled like this:
...
$ clang -g -gsplit-dwarf -flto *.c
...

Using readelf on the a.out to look at the generated dwarf, we get:
...
$ ~/binutils/install/bin/readelf -w a.out 2>&1 | more
The .debug_info section contains link(s) to dwo file(s):

  Name:  a.out_dwo/0.dwo
  Directory: /home/abuild/rpmbuild/BUILD/glibc-2.26/csu
  ID:d9 0e 49 4a b8 f0 7b f3

readelf: Warning: Unable to load dwo file:
/home/abuild/rpmbuild/BUILD/glibc-2.26/csu/a.out_dw
o/0.dwo
  Name:  a.out_dwo/0.dwo
  Directory: /home/vries/fission/fission-multi-cu
  ID:04 88 5d 18 be ef c8 0b

a.out: Found separate debug object file:
/home/vries/fission/fission-multi-cu/a.out_dwo/0.dwo
...

It seems the wrong directory was used for the first ID.

That is, the dir of one of the other CUs was used:
...
$ grep DW_AT_comp_dir.*: READELF | sed 's/:.*:/:/'
<24>   DW_AT_comp_dir: /home/abuild/rpmbuild/BUILD/glibc-2.26/csu
<43>   DW_AT_comp_dir: /home/abuild/rpmbuild/BUILD/glibc-2.26/csu
   DW_AT_comp_dir: /home/abuild/rpmbuild/BUILD/glibc-2.26/csu
   DW_AT_comp_dir: /home/vries/fission/fission-multi-cu
<107>   DW_AT_comp_dir: /home/vries/fission/fission-multi-cu
<13c>   DW_AT_comp_dir: /home/abuild/rpmbuild/BUILD/glibc-2.26/csu
<2f7>   DW_AT_comp_dir: /home/abuild/rpmbuild/BUILD/glibc-2.26/csu
...

The skeleton CUs look fine though, with the correct DW_AT_comp_dir:
...
 <0>: Abbrev Number: 1 (DW_TAG_compile_unit)
   DW_AT_stmt_list   : 0xe9
   DW_AT_comp_dir: /home/vries/fission/fission-multi-cu
   DW_AT_GNU_pubnames: 1
   DW_AT_GNU_dwo_name: a.out_dwo/0.dwo
   DW_AT_GNU_dwo_id  : 0xbc8efbe185d8804
   DW_AT_low_pc  : 0x4004a0
   DW_AT_high_pc : 0xf
   DW_AT_GNU_addr_base: 0x0
 <0><102>: Abbrev Number: 1 (DW_TAG_compile_unit)
<103>   DW_AT_stmt_list   : 0x13c
<107>   DW_AT_comp_dir: /home/vries/fission/fission-multi-cu
<10b>   DW_AT_GNU_pubnames: 1
<10b>   DW_AT_GNU_dwo_name: a.out_dwo/0.dwo
<10f>   DW_AT_GNU_dwo_id  : 0xf37bf0b84a490ed9
<117>   DW_AT_low_pc  : 0x4004b0
<11f>   DW_AT_high_pc : 0x14
<123>   DW_AT_GNU_addr_base: 0x0
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/26829] [readelf] wrong dir printed for .dwo file listing

2020-11-02 Thread vries at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=26829

--- Comment #1 from Tom de Vries  ---
Created attachment 12940
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12940&action=edit
tgz file containing a.out and 0.dwo

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/26806] Suspected linker bug with LTO

2020-11-02 Thread nickc at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=26806

--- Comment #13 from Nick Clifton  ---
FYI: Two new rawhide bugs have been filed since I updated the binutils with the
patch for this PR:

https://bugzilla.redhat.com/show_bug.cgi?id=1893404
https://bugzilla.redhat.com/show_bug.cgi?id=1893734

I have not investigated them yet, so they may well be unrelated or due to my
misapplying the patch.  Hence this post is just an informative one.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/26806] Suspected linker bug with LTO

2020-11-02 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=26806

--- Comment #14 from H.J. Lu  ---
(In reply to Nick Clifton from comment #13)
> FYI: Two new rawhide bugs have been filed since I updated the binutils with
> the patch for this PR:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1893404
> https://bugzilla.redhat.com/show_bug.cgi?id=1893734
> 
> I have not investigated them yet, so they may well be unrelated or due to my
> misapplying the patch.  Hence this post is just an informative one.

Please try users/hjl/pr26530/master branch:

https://gitlab.com/x86-binutils/binutils-gdb/-/commits/users/hjl/pr26530/master

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gold/26827] ld.gold --threads segfault since 2.35

2020-11-02 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=26827

--- Comment #1 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by Alan Modra :

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=af61e84fd2d6eca1273f1d24b8d7b89c5a1441e5

commit af61e84fd2d6eca1273f1d24b8d7b89c5a1441e5
Author: Nick Gasson 
Date:   Mon Nov 2 12:02:05 2020 +0800

gold: ensure file_counts_lock is initialized before using

Since upgrading to binutils 2.35 I've been experiencing random memory
corruption related crashes with ld.gold --threads. It's caused by
multiple threads concurrently pushing elements onto the shared
std::vector in File_read::record_file_read(). This vector is supposed to
be protected by file_counts_lock, but that is initialized lazily and
might be NULL when File_read::open() is called, in which case
Hold_optional_lock silently skips locking it.

Fix by calling the initialize() method before attempting to acquire the
lock, the same as other places that use file_counts_lock.

PR 26827
* fileread.cc (File_read::open): Ensure file_counts_lock is
initialized.
* testsuite/Makefile.am (check_PROGRAMS): Add a test that passes
-Wl,--threads.
* testsuite/Makefile.in: Regenerate.

-- 
You are receiving this mail because:
You are on the CC list for the bug.