[Bug gold/22820] ICF mismerges two very similar functions

2018-02-08 Thread ppluzhnikov at google dot com 
https://sourceware.org/bugzilla/show_bug.cgi?id=22820

Paul Pluzhnikov  changed:

   What|Removed |Added

 CC||ppluzhnikov at google dot com,
   ||tmsriram at google 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 binutils/22802] massive performance regression for `readelf -n`

2018-02-08 Thread robert at ocallahan dot org 
https://sourceware.org/bugzilla/show_bug.cgi?id=22802

--- Comment #4 from Robert O'Callahan  ---
Thanks for the quick response!

-- 
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/13671] gld creates i386 relocations not supported by Solaris ld.so.1

2018-02-08 Thread hjl.tools at gmail dot com 
https://sourceware.org/bugzilla/show_bug.cgi?id=13671

--- Comment #8 from H.J. Lu  ---
Does it look like a testcase?

[hjl@gnu-bdx-1 solaris-1]$ cat x.c
extern __thread int __gmpfr_flags;

int
_start (void)
{
  return __gmpfr_flags;
}
[hjl@gnu-bdx-1 solaris-1]$ cat y.c
__thread int __gmpfr_flags;
[hjl@gnu-bdx-1 solaris-1]$ make
gcc -m32 -fPIC   -c -o x.o x.c
gcc -m32 -fPIC   -c -o y.o y.c
./ld -m elf_i386_sol2 -shared -o y.so y.o
./ld -m elf_i386_sol2 -o x x.o y.so
readelf -r x

Relocation section '.rel.dyn' at offset 0x224 contains 1 entry:
 Offset InfoTypeSym.Value  Sym. Name
08049338  0225 R_386_TLS_TPOFF32    __gmpfr_flags
[hjl@gnu-bdx-1 solaris-1]$

-- 
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/22788] AddressSanitizer: SEGV /home/ubuntu/binutils/binutils_git/binutils-gdb/bfd/libbfd.c:558 bfd_getl32

2018-02-08 Thread hizhangsword at gmail dot com 
https://sourceware.org/bugzilla/show_bug.cgi?id=22788

--- Comment #5 from JayZhang  ---
Hi Nick,
   I have checked commit ef135d4314fd4c2d7da66b9d7b59af4a85b0f7e6,and found the
patch worked.
   Can we close the issue now and make it public?

  Best Regards
  JayZhang

-- 
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/22788] AddressSanitizer: SEGV /home/ubuntu/binutils/binutils_git/binutils-gdb/bfd/libbfd.c:558 bfd_getl32

2018-02-08 Thread cvs-commit at gcc dot gnu.org 
https://sourceware.org/bugzilla/show_bug.cgi?id=22788

--- Comment #3 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by Nick Clifton :

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

commit ef135d4314fd4c2d7da66b9d7b59af4a85b0f7e6
Author: Nick Clifton 
Date:   Thu Feb 8 10:28:25 2018 +

Fix a seg-fault in the ELF note parser when a note with an excessively
large alignment is encountered.

PR 22788
* elf.c (elf_parse_notes): Reject notes with excessuively large
alignments.

-- 
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/22788] AddressSanitizer: SEGV /home/ubuntu/binutils/binutils_git/binutils-gdb/bfd/libbfd.c:558 bfd_getl32

2018-02-08 Thread nickc at redhat dot com 
https://sourceware.org/bugzilla/show_bug.cgi?id=22788

Nick Clifton  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Nick Clifton  ---
Hi JayZhang,

  Exactly right.  The ELF note parsing code was not expecting such a large
  alignment, and that caused it to attempt to read beyond the end of the
  buffer containing the note.

  I have checked in the patch, so the problem should now be fixed.

Cheers
  Nick

-- 
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/13671] gld creates i386 relocations not supported by Solaris ld.so.1

2018-02-08 Thread hjl.tools at gmail dot com 
https://sourceware.org/bugzilla/show_bug.cgi?id=13671

--- Comment #9 from H.J. Lu  ---
There are many Linux TLS tests under ld/testsuite/ld-i386.  But they run
only for Linux targets.  Please figure out:

1. Which TLS code sequences are also generated by Solaris GCC.
2. Among them, which TLS transitions for Linux should be disabled
for Solaris.

-- 
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/22820] New: ICF mismerges two very similar functions

2018-02-08 Thread steinar+binutils at gunderson dot no 
https://sourceware.org/bugzilla/show_bug.cgi?id=22820

Bug ID: 22820
   Summary: ICF mismerges two very similar functions
   Product: binutils
   Version: 2.30
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: gold
  Assignee: ccoutant at gmail dot com
  Reporter: steinar+binutils at gunderson dot no
CC: ian at airs dot com
  Target Milestone: ---

Hi,

We had a fairly bad data dictionary corruption bug in MySQL, which we
eventually traced down to gold mistakenly ICF-ing two functions that are
actually different. My understanding of the problem is that the two functions
are _bytewise_ identical, but since they refer to different constants using
%rip-relative addressing, they still would execute differently, and thus should
not be merged.

Here's a test case (compiled with GCC 7.3):

atum17:~/reduce5> cat dictionary_impl.cc
#include 

int func(std::string);

int get_actual_P_S_version() {
  return func("PS_VERSION");
}
int get_actual_I_S_version() {
  return func("IS_VERSION");
} 
atum17:~/reduce5> g++ -O2 -fPIC -ffunction-sections -fdata-sections -o
dictionary_impl.o -c dictionary_impl.cc
atum17:~/reduce5> g++ -fuse-ld=gold -Wl,--icf=safe -shared -o
dictionary_impl.so dictionary_impl.o
atum17:~/reduce5> nm --demangle dictionary_impl.so | grep get_actual

0a50 T get_actual_I_S_version()
0a50 T get_actual_P_S_version()

So the two functions have received the same address in the binary, and thus
were incorrectly merged.

-- 
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/22802] massive performance regression for `readelf -n`

2018-02-08 Thread cvs-commit at gcc dot gnu.org 
https://sourceware.org/bugzilla/show_bug.cgi?id=22802

--- Comment #2 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by Nick Clifton :

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

commit 8de3a6e2afe21ac93d610fa46fbc579a81ea2277
Author: Nick Clifton 
Date:   Thu Feb 8 12:29:07 2018 +

Speed up readelf and objdump by not looking for DWO links unless the user
has requested that they be displayed/followed.

PR 22802
* dwarf.c (load_separate_debug_file): Return early if the user is
not interested in debug links.

-- 
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/13671] gld creates i386 relocations not supported by Solaris ld.so.1

2018-02-08 Thread ro at CeBiTec dot Uni-Bielefeld.DE 
https://sourceware.org/bugzilla/show_bug.cgi?id=13671

--- Comment #7 from Rainer Orth  ---
> --- Comment #6 from H.J. Lu  ---
[...]
> Please provide one separate testcase in assembly code for each instance
> where ld creates dynamic relocs Solaris ld.so.1 cannot handle.

I'm trying, but I have a hard time even for the case at hand:

There's not only one, but a couple of those relocs in cc1:

Relocation Section:  .rel.dyn
   index  typeoffset value  section  symbol
[...]
   [189]  R_386_UNKNOWN37  0x9c79cf4 0  .got __gmpfr_emin
   [390]  R_386_UNKNOWN37  0x9c7a01c 0  .got
__gmpfr_default_rounding_mode
   [430]  R_386_UNKNOWN37  0x9c7a0bc 0  .got
__gmpfr_cache_const_log2
   [432]  R_386_UNKNOWN37  0x9c7a0c4 0  .got __gmpfr_flags
   [546]  R_386_UNKNOWN37  0x9c7a28c 0  .got
__gmpfr_cache_const_catalan
  [1069]  R_386_UNKNOWN37  0x9c7aab8 0  .got
__gmpfr_cache_const_euler
  [1225]  R_386_UNKNOWN37  0x9c7ad28 0  .got __gmpfr_emax
  [1330]  R_386_UNKNOWN37  0x9c7aecc 0  .got
__gmpfr_default_fp_bit_precision
  [1467]  R_386_UNKNOWN37  0x9c7b0f0 0  .got
__gmpfr_cache_const_pi

The definitions are from libmpfr.a (built with --disable-shared
--with-pic), e.g.

   [22]  0   0x4  TLS  GLOB  D0 .tbss  __gmpfr_flags

In the gld-linked cc1, I find

Symbol Table Section:  .dynsym
   [5850]   0x6c 0x4  TLS  GLOB  D1 .tbss __gmpfr_flags

Global Offset Table Section:  .got
   [584]  0x9c7a0c4 0  R_386_UNKNOWN37 __gmpfr_flags

Relocation Section:  .rel.dyn
   [432]  R_386_UNKNOWN37  0x9c7a0c4 0  .got __gmpfr_flags

while in the ld-linked cc1, there is only:

Symbol Table Section:  .dynsym
   [14735]   0x6c 0x4  TLS  GLOB  D1 .tbss__gmpfr_flags

The toolchains are otherwise identical, both using gas 2.30 with either
Solaris ld or gld 2.30, both trees configured with --enable-host-shared,
no (relevant) differences in auto-host.h.

In the ld-linked cc1, there are no got entries for __gmpfr_* symbols at
all.

So far, I've not managed to create a testcase from this.

-- 
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/22802] massive performance regression for `readelf -n`

2018-02-08 Thread nickc at redhat dot com 
https://sourceware.org/bugzilla/show_bug.cgi?id=22802

Nick Clifton  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||nickc at redhat dot com
 Resolution|--- |FIXED

--- Comment #3 from Nick Clifton  ---
Hi Robert,

  Sorry - this was my fault.  The new code to follow debug links
  was looking for DWO links, even if the user was not interested
  in them.  Finding DWO links involves reading in processing pretty
  much all of the .debug_info section, which in a file with a lot
  of debug information can take a long time.

  I have checked in a small patch to stop the search for DWO links
  unless the user has provided the --debug=links or --debug=follow-links
  options.  This should give you back your millisecond response times.

Cheers
  Nick

-- 
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