[Bug ld/20828] [MIPS] produces invalid dynamic symbol table when --gc-sections is used since PR ld/13177 fix

2017-01-11 Thread glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=20828

--- Comment #14 from John Paul Adrian Glaubitz  ---
Hi Maciej!

(In reply to Maciej W. Rozycki from comment #12)
> There's been no further feedback from other people and myself I haven't
> made up my mind about this bug yet, so if you are blocked with your
> work, then for the time being please use one of the proposals posted
> here as a temporary workaround.

The problem with this approach is that our toolchain maintainers are unwilling
to merge a patch which has not been fully approved upstream for a supported
target architecture.

This means, the binutils package in Debian is still broken on all MIPS targets
(mips32 big-endian, mips32 little-endian, mips64 little-endian) in Debian and
if the issue is not resolved within the near future, the upcoming Debian
Stretch release may be shipped without any official support for MIPS [1].

So, from the Debian point-of-view, fixing this bug has urgent priority unless
we want to waive for MIPS support.

Thanks,
Adrian

> [1] https://release.debian.org/stretch/arch_qualify.html

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


ld: once multiple symbol definitions are allowed, both definitions end up in the executable

2017-01-11 Thread Pavel Shishpor
Hello,

Could please someone advice is it a bug or a feature when we get both
bodies of the functions with the same name in the executable once multiple
symbol definitions are allowed? Here is the example showing the behavior:

$ cat main.c

int f() {return 6;}
int main() { return f();}

$ cat a.c

int f() {return 4;}

$ gcc -c a.c main.c
$ gcc -Wl,--allow-multiple-definition a.o main.o

# From objdump we can see that the bodies of both functions "f" end up in
the executable:
$ objdump -d a.out

004004f6 :
  4004f6:55   push   %rbp
  4004f7:48 89 e5 mov%rsp,%rbp
  4004fa:b8 04 00 00 00   mov$0x4,%eax
  4004ff:5d   pop%rbp
  400500:c3   retq
  400501:55   push   %rbp
  400502:48 89 e5 mov%rsp,%rbp
  400505:b8 06 00 00 00   mov$0x6,%eax
  40050a:5d   pop%rbp
  40050b:c3   retq

# The behavior is more or less as specified in the documentation with only
the first definition executed:
$ ./a.out
$ echo $?
4
$


In my (more complex) setup I saw issues coming from this behavior since not
only we get the second definition but the relocations needed by it.

Just in case some more information on my setup (though the behavior is the
same on one more Linux host and the issue looks to be there on more recent
ld also):
$ gcc --version
gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
$ ld --version
GNU ld version 2.25-9.fc22

Best regards,
Pavel
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/20876] objdump is not aware about the build ID method to find detached debug info

2017-01-11 Thread mark at klomp dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=20876

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

--- Comment #3 from Mark Wielaard  ---
Just a note that elfutils searches only the (global?) absolute debuginfo paths
directly.

So given the default of "":.debug:/usr/lib/debug", it skips the "" relative cwd
and the ".debug" postfix, but only tries /usr/lib/debug/.build-id/xx/.debug

So the search strategy of elfutils for a separate .debug file given a build-id
xx and a list of debuginfo search paths is to take the absolute paths
(starting with '/') and trying /path/.build-id/xx/.debug. Where the default
list of (absolute) debuginfo search paths is just "/usr/lib/debug". It then
takes the canonicalize_file_name assuming it might be a symlink and the user
might find the resolved name more interesting. As a sanity check elfutils also
only allows build-ids that are at a minimum 4 and at a maximum 64 hex
characters long. It does normally also verify that the found file does contain
the build-id it should and reject the file if it doesn't.

-- 
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/13442] gold screws up exception handling with --incremental flag

2017-01-11 Thread matt at godbolt dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=13442

Matt Godbolt  changed:

   What|Removed |Added

 CC||matt at godbolt dot org

--- Comment #10 from Matt Godbolt  ---
On a whim I tried incremental linking on our existing large codebase and hit
this exact same problem.

This happens with Ubuntu 14.04's default g++ 4.8.4 and gold 1.11 (binutils
2.24) reproduced using Samuel's steps (adding -fuse-ld=gold).

It also happens with a custom-built GCC 6.3.0 with an in-tree build of gold
(binutils 2.26, gold 1.11) - though in order to get around the plugin support
built into this build the repro case needs -fno-lto too.

-- 
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/20828] [MIPS] produces invalid dynamic symbol table when --gc-sections is used since PR ld/13177 fix

2017-01-11 Thread ma...@linux-mips.org
https://sourceware.org/bugzilla/show_bug.cgi?id=20828

Maciej W. Rozycki  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #15 from Maciej W. Rozycki  ---
I can't comment on individual distribution policies here, this is not the
right place to discuss them.

As per the milestone set this will be fixed with 2.28.  If this does not
satisfy your distribution's requirements, then you have several options
to choose from, including but possibly not limited to these:

1. Propose a change suitable for inclusion with our sources; I have
   outlined one earlier on although there may be other acceptable ways to
   do it too.

2. Temporarily use one of the quick fixes proposed here.

3. Work the problem around by disabling linker GC.

It is then up to individual distribution's maintainers to decide which of
these options suits them best; in particular submitting a change that can
be accepted right away is always welcome and guarantees quick processing.

NB while I'll implement the missing dynsym ordering case for the MIPS
backend so that it follows the ELF gABI even if weird output is somehow
produced by the generic BFD ELF linker I maintain that dropping symbols
that have been GC-ed (but not other forced local ones) is the right
solution.

-- 
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/21038] New: Incorrect unwind info for BND PLT

2017-01-11 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=21038

Bug ID: 21038
   Summary: Incorrect unwind info for BND PLT
   Product: binutils
   Version: 2.29 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: x86-64

[hjl@gnu-6 mpx-6]$ cat y.S 
.text
.globl foo
.type foo, @function
foo:
.cfi_startproc
callfunc@plt
.cfi_endproc
[hjl@gnu-6 mpx-6]$ make LD=ld
gcc -B./-c -o y.o y.S
ld -z bndplt -shared -o y.so y.o
./objdump -Wf -dw y.so

y.so: file format elf64-x86-64

Contents of the .eh_frame section:

 0014  CIE
  Version:   1
  Augmentation:  "zR"
  Code alignment factor: 1
  Data alignment factor: -8
  Return address column: 16
  Augmentation data: 1b

  DW_CFA_def_cfa: r7 (rsp) ofs 8
  DW_CFA_offset: r16 (rip) at cfa-8
  DW_CFA_nop
  DW_CFA_nop

0018 0014 001c FDE cie=
pc=0248..024d
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop

0030 0024 0034 FDE cie=
pc=0220..0240
  DW_CFA_def_cfa_offset: 16
  DW_CFA_advance_loc: 6 to 0226
  DW_CFA_def_cfa_offset: 24
  DW_CFA_advance_loc: 10 to 0230
  DW_CFA_def_cfa_expression (DW_OP_breg7 (rsp): 8; DW_OP_breg16 (rip): 0;
DW_OP_lit15; DW_OP_and; DW_OP_lit11; DW_OP_ge; DW_OP_lit3; DW_OP_shl;
DW_OP_plus)
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop


Disassembly of section .plt:

0220 <.plt>:
 220:   ff 35 e2 0d 20 00   pushq  0x200de2(%rip)# 201008
<_GLOBAL_OFFSET_TABLE_+0x8>
 226:   f2 ff 25 e3 0d 20 00bnd jmpq *0x200de3(%rip)# 201010
<_GLOBAL_OFFSET_TABLE_+0x10>
 22d:   0f 1f 00nopl   (%rax)
 230:   68 00 00 00 00  pushq  $0x0
 235:   f2 e9 e5 ff ff ff   bnd jmpq 220 <.plt>
 23b:   0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)

Disassembly of section .plt.bnd:

0240 :
 240:   f2 ff 25 d1 0d 20 00bnd jmpq *0x200dd1(%rip)# 201018 
 247:   90  nop

Disassembly of section .text:

0248 :
 248:   e8 f3 ff ff ff  callq  240 
[hjl@gnu-6 mpx-6]$ 

Since the BND PLT has

 230:   68 00 00 00 00  pushq  $0x0
 235:   f2 e9 e5 ff ff ff   bnd jmpq 220 <.plt>
 23b:   0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)

instead of

 230:   ff 25 e2 0d 20 00   jmpq   *0x200de2(%rip)# 201018 
 236:   68 00 00 00 00  pushq  $0x0
 23b:   e9 e0 ff ff ff  jmpq   220 <.plt>

Its unwind info should be

  DW_CFA_def_cfa_expression (DW_OP_breg7 (rsp): 8; DW_OP_breg16 (rip): 0;
DW_OP_lit15; DW_OP_and; DW_OP_lit5; DW_OP_ge; DW_OP_lit3; DW_OP_shl;
DW_OP_plus)

-- 
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/20876] objdump is not aware about the build ID method to find detached debug info

2017-01-11 Thread nickc at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20876

Nick Clifton  changed:

   What|Removed |Added

   Attachment #9746|0   |1
is obsolete||

--- Comment #4 from Nick Clifton  ---
Created attachment 9748
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9748&action=edit
Proposed patch

Hi Matthias,

  OK, here is a revised patch.  Please let me know what you think.

  I have not added build-id verification as I am lazy, but that can be done
  if you are happy with the rest of the patch.

  More controversially however, I have not restricted the path generation to
  absolute paths.  The reason is basically testing.  If the build-id based
  debug info files *have* to be installed into admin controlled parts of the
  file system then it is not going to be possible to test the feature as an
  ordinary user.  (See the addition to objdump.exp in the updated patch for
  an example of how I envisage testing the feature currently).

  Is it such a bad thing to be able to load locally stored build-id based
  debug info files ?  It makes testing possible, and I imagine that it
  would be quite useful in development too.  If the user wants to debug a
  built, but not installed, application (which uses build-id based separate
  debug files), then all that they need to do is to make sure that the files
  are in the correct .build-id/NN directories and away they go.

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/21038] Incorrect unwind info for BND PLT

2017-01-11 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=21038

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |2.29

--- Comment #2 from H.J. Lu  ---
Fixed.

-- 
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/21038] Incorrect unwind info for BND PLT

2017-01-11 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=21038

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

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

commit 9e65917652e994b0864b344bfa47014155d93100
Author: H.J. Lu 
Date:   Wed Jan 11 09:16:44 2017 -0800

x86-64: Correct unwind info for the BND PLT

Since the BND PLT has

 230:   68 00 00 00 00  pushq  $0x0
 235:   f2 e9 e5 ff ff ff   bnd jmpq 220 <.plt>
 23b:   0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)

instead of

 230:   ff 25 e2 0d 20 00   jmpq   *0x200de2(%rip)# 201018

 236:   68 00 00 00 00  pushq  $0x0
 23b:   e9 e0 ff ff ff  jmpq   220 <.plt>

its unwind info should be

DW_CFA_def_cfa_expression (DW_OP_breg7 (rsp): 8; DW_OP_breg16 (rip): 0;
DW_OP_lit15; DW_OP_and; DW_OP_lit5; DW_OP_ge; DW_OP_lit3; DW_OP_shl;
DW_OP_plus)

bfd/

PR ld/21038
* elf64-x86-64.c (elf_x86_64_eh_frame_bnd_plt): New.
(elf_x86_64_bnd_arch_bed): Use elf_x86_64_eh_frame_bnd_plt and
elf_x86_64_eh_frame_plt_got.
(elf_x86_64_size_dynamic_sections): Get unwind info from
elf_x86_64_bnd_arch_bed for the BND PLT.

ld/

PR ld/21038
* testsuite/ld-x86-64/pr21038a.d: New file.
* testsuite/ld-x86-64/pr21038a.s: Likewise.
* testsuite/ld-x86-64/pr21038b.d: Likewise.
* testsuite/ld-x86-64/pr21038b.s: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Run pr21038a and pr21038b.

-- 
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/21039] New: Tests fail on i386-linux

2017-01-11 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=21039

Bug ID: 21039
   Summary: Tests fail on i386-linux
   Product: binutils
   Version: 2.29 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: gold
  Assignee: ccoutant at gmail dot com
  Reporter: hjl.tools at gmail dot com
CC: ian at airs dot com
  Target Milestone: ---
Target: i386

On Linux/i386, I got

FAIL: script_test_13.sh
FAIL: script_test_15a.sh
FAIL: script_test_15b.sh
FAIL: script_test_15c.sh

FAIL: script_test_13.sh (exit: 1)
=

Expected pattern was not found:
\.rela\.dyn[[:space:]]\+RELA[[:space:]]\+0\+1\b

Actual output below:
There are 20 section headers, starting at offset 0x257c:

Section Headers:
  [Nr] Name  TypeAddr OffSize   ES Flg Lk Inf
Al
  [ 0]   NULL 00 00 00  0   0 
0
  [ 1] .text PROGBITS 001000 00 00  AX  0   0 
1
  [ 2] .dynsym   DYNSYM   001000 30 10   A  3   1 
4
  [ 3] .dynstr   STRTAB  0030 001030 06 00   A  0   0 
1
  [ 4] .hash HASH0038 001038 18 04   A  2   0 
4
  [ 5] .data PROGBITS0050 001050 00 00  WA  0   0 
1
  [ 6] .data.rel PROGBITS0050 001050 04 00  WA  0   0 
4
  [ 7] .dynamic  DYNAMIC 0054 001054 70 08  WA  3   0 
4
  [ 8] .rel.dyn  REL 0001 002000 08 08   A  2   0 
4
  [ 9] .bss  NOBITS  00010229 002229 00 00  WA  0   0 
1
  [10] .debug_abbrev PROGBITS 002229 48 00  0   0 
1
  [11] .debug_info   PROGBITS 002271 4b 00  0   0 
1
  [12] .debug_line   PROGBITS 0022bc 76 00  0   0 
1
  [13] .debug_pubnames   PROGBITS 002332 19 00  0   0 
1
  [14] .debug_strPROGBITS 00234b 99 01  MS  0   0 
1
  [15] .comment  PROGBITS 0023e4 49 01  MS  0   0 
1
  [16] .note.gnu.gold-version NOTE 002430 1c 00  0 
 0  4
  [17] .symtab   SYMTAB   00244c 50 10 18   3 
4
  [18] .strtab   STRTAB   00249c 20 00  0   0 
1
  [19] .shstrtab STRTAB   0024bc bf 00  0   0 
1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  p (processor specific)

-- 
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/21040] New: Gold fails with GCC 4.2

2017-01-11 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=21040

Bug ID: 21040
   Summary: Gold fails with GCC 4.2
   Product: binutils
   Version: 2.29 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: gold
  Assignee: ccoutant at gmail dot com
  Reporter: hjl.tools at gmail dot com
CC: ian at airs dot com
  Target Milestone: ---

With GCC 4.2, I got

gold/x86_64.cc:481: error: using ‘typename’ outside of template
...
gold/powerpc.cc:2013: warning: comparison is always false due to limited range
of data type
...
gold/testsuite/copy_test_relro_1.cc:24: warning: ‘p’ initialized and declared
‘extern’

-- 
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/21039] Tests fail on i386-linux

2017-01-11 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=21039

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

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

commit 1fa5f68bf38fc29f173990614db70fed1b66c0e0
Author: Cary Coutant 
Date:   Wed Jan 11 11:26:26 2017 -0800

Fix test cases to work for i386.

gold/
PR gold/21039
* testsuite/script_test_13.sh: Adjust patterns to work for i386.
* testsuite/script_test_15a.sh: Likewise.
* testsuite/script_test_15b.sh: Likewise.
* testsuite/script_test_15c.sh: Likewise.

-- 
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/21039] Tests fail on i386-linux

2017-01-11 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=21039

--- Comment #2 from cvs-commit at gcc dot gnu.org  ---
The binutils-2_28-branch branch has been updated by Cary Coutant
:

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

commit a513f8bec2a8be13196960372b477231af8f76a2
Author: Cary Coutant 
Date:   Wed Jan 11 11:26:26 2017 -0800

Fix test cases to work for i386.

gold/
PR gold/21039
* testsuite/script_test_13.sh: Adjust patterns to work for i386.
* testsuite/script_test_15a.sh: Likewise.
* testsuite/script_test_15b.sh: Likewise.
* testsuite/script_test_15c.sh: Likewise.

-- 
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/21039] Tests fail on i386-linux

2017-01-11 Thread ccoutant at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=21039

Cary Coutant  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Cary Coutant  ---
Fixed on trunk and binutils-2_28-branch.

-- 
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/20876] objdump is not aware about the build ID method to find detached debug info

2017-01-11 Thread doko at debian dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=20876

--- Comment #5 from Matthias Klose  ---
no, still doesn't strip the dirname, and one location is search twice.

open("/usr/lib/debug/bin/.build-id/1b/1d2d0a5c825e50e07e80595427894ef0af116b.debug",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/debug/usr/bin/.build-id/1b/1d2d0a5c825e50e07e80595427894ef0af116b.debug",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/debug/bin/.build-id/1b/1d2d0a5c825e50e07e80595427894ef0af116b.debug",
O_RDONLY) = -1 ENOENT (No such file or directory)

-- 
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/21040] Gold fails with GCC 4.2

2017-01-11 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=21040

--- Comment #3 from cvs-commit at gcc dot gnu.org  ---
The binutils-2_28-branch branch has been updated by Cary Coutant
:

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

commit 930624ccb207a0e1bb16500a4d812e9671fb78de
Author: Cary Coutant 
Date:   Wed Jan 11 11:47:27 2017 -0800

Fix compile errors with GCC 4.2.

gold/
PR gold/21040
* x86_64.cc (Output_data_plt_x86_64_bnd::do_fill_first_plt_entry):
Remove unnecessary 'typename' keyword.
(Output_data_plt_x86_64_bnd::do_fill_plt_entry): Likewise.
(Output_data_plt_x86_64_bnd::do_fill_tlsdesc_entry): Likewise.
(Output_data_plt_x86_64_bnd::fill_aplt_entry): Likewise.
* testsuite/copy_test_relro_1.cc (p, b, c, q): Add separate extern
declarations.

-- 
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/21040] Gold fails with GCC 4.2

2017-01-11 Thread ccoutant at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=21040

Cary Coutant  changed:

   What|Removed |Added

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


Re: ld: once multiple symbol definitions are allowed, both definitions end up in the executable

2017-01-11 Thread Jim Wilson

On 01/11/2017 01:49 AM, Pavel Shishpor wrote:

Could please someone advice is it a bug or a feature when we get both
bodies of the functions with the same name in the executable once
multiple symbol definitions are allowed? Here is the example showing the
behavior:


The only thing that the --allow-multiple-definitions option does is 
disable the error message that you would normally get.  It doesn't 
change how the linker output is created.  So yes, you will end up with 
both definitions in the output.


It is best to avoid getting multiple definitions in the first place.

If you want the linker to discard unused functions, then each function 
must be in its own section via gcc -ffunction-sections and then use the 
linker --gc-sections option.  However, this may cause problems of its 
own, e.g. debug functions may disappear because they appear unused, it 
won't work for libraries where most functions are meant to be used by an 
application it is linked with, etc.  Or alternatively, you can try 
making it a COMDAT function, then duplicates get dropped automatically.


For your example, the duplicate f function is in the same text section 
as the main function, which can't be deleted.  The assembler may resolve 
intra-section references itself.  Which means editing the text section 
to remove the f function may break other things in the same section, 
which is unsafe, and hence the linker can't do it.  Thus the requirement 
that we can only delete functions that are in their own section.


Jim


___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gold/21040] Gold fails with GCC 4.2

2017-01-11 Thread ccoutant at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=21040

--- Comment #1 from Cary Coutant  ---
> gold/powerpc.cc:2013: warning: comparison is always false due to limited
> range of data type

Alan, I'll leave this one to you. Not sure whether you want to cast addr to
uint64_t or not.

-- 
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/21040] Gold fails with GCC 4.2

2017-01-11 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=21040

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

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

commit 976e204b369fd01f9d35d87ea2cd07707c3a40cf
Author: Cary Coutant 
Date:   Wed Jan 11 11:47:27 2017 -0800

Fix compile errors with GCC 4.2.

gold/
PR gold/21040
* x86_64.cc (Output_data_plt_x86_64_bnd::do_fill_first_plt_entry):
Remove unnecessary 'typename' keyword.
(Output_data_plt_x86_64_bnd::do_fill_plt_entry): Likewise.
(Output_data_plt_x86_64_bnd::do_fill_tlsdesc_entry): Likewise.
(Output_data_plt_x86_64_bnd::fill_aplt_entry): Likewise.
* testsuite/copy_test_relro_1.cc (p, b, c, q): Add separate extern
declarations.

-- 
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/20876] objdump is not aware about the build ID method to find detached debug info

2017-01-11 Thread doko at debian dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=20876

--- Comment #6 from Matthias Klose  ---
applying this on top of your patch works for me. The global debug directory
doesn't have the dirname of the original file, so don't append `canon_dir'. 
Not sure if that needs to be stripped from the tests with EXTRA_DEBUG_ROOT1 and
EXTRA_DEBUG_ROOT2 prefixes as well?

--- bfd/opncls.c~   2017-01-11 20:29:07.061189932 +0100
+++ bfd/opncls.c2017-01-11 21:39:51.211288793 +0100
@@ -1481,11 +1481,8 @@
   /* Then try in the global debugfile directory.  */
   strcpy (debugfile, debug_file_directory);
   dirlen = strlen (debug_file_directory) - 1;
-  if (dirlen > 0
-  && debug_file_directory[dirlen] != '/'
-  && canon_dir[0] != '/')
+  if (dirlen > 0 && debug_file_directory[dirlen] != '/')
 strcat (debugfile, "/");
-  strcat (debugfile, canon_dir);
   strcat (debugfile, base);

   if (check_func (debugfile, crc32))

-- 
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/21040] Gold fails with GCC 4.2

2017-01-11 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=21040

--- Comment #5 from cvs-commit at gcc dot gnu.org  ---
The binutils-2_28-branch branch has been updated by Cary Coutant
:

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

commit c5cb17ebcfe6d375a7b85dd6014306b1ef473a2f
Author: Cary Coutant 
Date:   Wed Jan 11 13:42:24 2017 -0800

Fix more compile errors with GCC 4.2.

gold/
PR gold/21040
* x86_64.cc (Output_data_plt_x86_64_bnd::do_fill_first_plt_entry):
Remove unnecessary 'typename' keyword.
(Output_data_plt_x86_64_bnd::do_fill_plt_entry): Likewise.
(Output_data_plt_x86_64_bnd::fill_aplt_entry): Likewise.
(Output_data_plt_x86_64_bnd::do_fill_tlsdesc_entry): Likewise.
(Output_data_plt_x86_64_bnd::do_write): Likewise.

-- 
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/21040] Gold fails with GCC 4.2

2017-01-11 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=21040

--- Comment #4 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by Cary Coutant :

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

commit 6624f3a142811450fab7eed1f406c4a030c3c9be
Author: Cary Coutant 
Date:   Wed Jan 11 13:42:24 2017 -0800

Fix more compile errors with GCC 4.2.

gold/
PR gold/21040
* x86_64.cc (Output_data_plt_x86_64_bnd::do_fill_first_plt_entry):
Remove unnecessary 'typename' keyword.
(Output_data_plt_x86_64_bnd::do_fill_plt_entry): Likewise.
(Output_data_plt_x86_64_bnd::fill_aplt_entry): Likewise.
(Output_data_plt_x86_64_bnd::do_fill_tlsdesc_entry): Likewise.
(Output_data_plt_x86_64_bnd::do_write): Likewise.

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