[Bug gold/22791] Don't error when a -pie executable uses a shared function without PIC/PIE relocation

[rafael.espindola at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22791

--- Comment #11 from Rafael Ávila de Espíndola  ---
(In reply to Cary Coutant from comment #10)
> The "official" or "canonical" PLT entry is the one that serves as the
> address of the function throughout the program.

OK, so we were talking about the same plt entry.

> If you make the function protected in your shared library, I think the PIC
> sequence to get its address will always load the address of the function
> itself, while the PC32 relocation in the main program will have no
> alternative but to load the address of its own PLT entry. (Gnu ld will
> refuse to build a shared library with a PC32 ref to a protected symbol, but
> gold will build it.)

That is what I would expect. Using a PLT entry in the main executable as the
canonical PLT entry should work in the same cases where a copy relocation
works: The use is in the main program and the definition has default
visibility.

-- 
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/22791] Don't error when a -pie executable uses a shared function without PIC/PIE relocation

[ccoutant at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22791

--- Comment #10 from Cary Coutant  ---
The "official" or "canonical" PLT entry is the one that serves as the address
of the function throughout the program.

If you make the function protected in your shared library, I think the PIC
sequence to get its address will always load the address of the function
itself, while the PC32 relocation in the main program will have no alternative
but to load the address of its own PLT entry. (Gnu ld will refuse to build a
shared library with a PC32 ref to a protected symbol, but gold will build it.)

That's probably not the only way to break function pointer comparison. I'm just
really leery of treating this relocation as PIC-/PIE-compatible.

-- 
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/22791] Don't error when a -pie executable uses a shared function without PIC/PIE relocation

[rafael.espindola at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22791

--- Comment #9 from Rafael Ávila de Espíndola  ---
(In reply to Cary Coutant from comment #8)
> (In reply to Rafael Ávila de Espíndola from comment #5)
> > (In reply to Cary Coutant from comment #4)
> > > This would be fine if we knew for a fact that the relocation is on a call
> > > instruction. The problem is that R_X86_64_PC32 isn't always a call
> > > instruction.
> > 
> > It still works. The library will see the address of the got entry.
> 
> Which won't necessarily be the "official" PLT entry. Function point
> comparison may break.

Not sure what you mean by "official". The testcase I uploaded computes address
of an external function foo with

movslq  bar(%rip), %rax
leaqbar(%rip), %rdi
addq%rax, %rdi
...
.data
.p2align3
bar:
.long   foo - .

and in a shared library foo is defined as

void foo(void *bar) {
  printf("%p %p\n", bar, foo);
}

I always get the same value printed twice.

-- 
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/22791] Don't error when a -pie executable uses a shared function without PIC/PIE relocation

[ccoutant at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22791

--- Comment #8 from Cary Coutant  ---
(In reply to Rafael Ávila de Espíndola from comment #5)
> (In reply to Cary Coutant from comment #4)
> > This would be fine if we knew for a fact that the relocation is on a call
> > instruction. The problem is that R_X86_64_PC32 isn't always a call
> > instruction.
> 
> It still works. The library will see the address of the got entry.

Which won't necessarily be the "official" PLT entry. Function point comparison
may break.

-- 
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/22791] Don't error when a -pie executable uses a shared function without PIC/PIE relocation

[rafael.espindola at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22791

--- Comment #7 from Rafael Ávila de Espíndola  ---
(In reply to Rafael Ávila de Espíndola from comment #5)
> (In reply to Cary Coutant from comment #4)
> > This would be fine if we knew for a fact that the relocation is on a call
> > instruction. The problem is that R_X86_64_PC32 isn't always a call
> > instruction.
> 
> It still works. The library will see the address of the got entry.
> 
> I will upload a testcase.

s/got/plt/

-- 
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/22791] Don't error when a -pie executable uses a shared function without PIC/PIE relocation

[rafael.espindola at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22791

--- Comment #6 from Rafael Ávila de Espíndola  ---
Created attachment 10787
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10787=edit
testcase that prints the address of a function

-- 
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/22791] Don't error when a -pie executable uses a shared function without PIC/PIE relocation

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22791

H.J. Lu  changed:

   What|Removed |Added

Summary|Don't error when a -pie |Don't error when a -pie
   |executable uses a shared|executable uses a shared
   |function without a got  |function without PIC/PIE
   ||relocation

-- 
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/22791] Don't error when a -pie executable uses a shared function without a got

[ccoutant at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22791

--- Comment #4 from Cary Coutant  ---
This would be fine if we knew for a fact that the relocation is on a call
instruction. The problem is that R_X86_64_PC32 isn't always a call instruction.

-- 
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/22791] Don't error when a -pie executable uses a shared function without a got

[rafael.espindola at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22791

--- Comment #3 from Rafael Ávila de Espíndola  ---
It seems to work. The attached hello world has

Type:  DYN (Shared object file)

 6: 11e0 0 FUNCGLOBAL DEFAULT  UND puts@GLIBC_2.2.5

and it works.

-- 
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/22791] Don't error when a -pie executable uses a shared function without a got

[rafael.espindola at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22791

--- Comment #2 from Rafael Ávila de Espíndola  ---
Created attachment 10786
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10786=edit
testcase

-- 
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/22791] Don't error when a -pie executable uses a shared function without a got

[amodra at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22791

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

--- Comment #1 from Alan Modra  ---
> But there is no reason why trick of defining a symbol pointing to the plt 
> entry > would not work with a PIE.

Does ld.so process SHN_UNDEF symbols with non-zero value properly in a PIE?

-- 
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/22791] New: Don't error when a -pie executable uses a shared function without a got

[rafael.espindola at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22791

Bug ID: 22791
   Summary: Don't error when a -pie executable uses a shared
function without a got
   Product: binutils
   Version: unspecified
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: gold
  Assignee: ccoutant at gmail dot com
  Reporter: rafael.espindola at gmail dot com
CC: ian at airs dot com
  Target Milestone: ---

The following testcase fails with gold

$ cat test.s
.globl  _start
_start:
callq   vcall
$ cat test2.s
.global vcall
.type vcall,@function
vcall:
nop
$ ld.gold test2.o -o test2.so -shared
$ ld.gold test.o test2.so -o t -pie
ld.gold: error: test.o: requires dynamic R_X86_64_PC32 reloc against 'vcall'
which may overflow at runtime; recompile with -fPIC

But there is no reason why trick of defining a symbol pointing to the plt entry
would not work with a PIE.

Starting with c5bb8910e80c6cd80c63541f86471c18375c8198 bfd uses TEXTREL, but
that seems less desirable than creating a symbol pointing to the plt entry as
is done in the non -pie case.

-- 
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/22791] Don't error when a -pie executable uses a shared function without a got

[rafael.espindola at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22791

Rafael Ávila de Espíndola  changed:

   What|Removed |Added

 CC||ccoutant 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 ld/22764] [2.30 Regression] ld fails to link 4.13 and 4.15 kernels on aarch64-linux-gnu

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=22764

--- Comment #15 from cvs-commit at gcc dot gnu.org  ---
The binutils-2_30-branch branch has been updated by Renlin Li
:

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

commit b01452b1d44a586f4ecf5cf02ffc0643e4962324
Author: Renlin Li 
Date:   Sat Feb 3 13:18:17 2018 +

[PR22764][LD][AARCH64]Allow R_AARCH64_ABS16 and R_AARCH64_ABS32 against
absolution symbol or undefine symbol in shared object.

backport from mainline

bfd/

2018-02-05  Renlin Li  

PR ld/22764
* elfnn-aarch64.c (elfNN_aarch64_check_relocs): Relax the
R_AARCH64_ABS32 and R_AARCH64_ABS16 for absolute symbol. Apply the
check for writeable section as well.

ld/

2018-02-05  Renlin Li  

PR ld/22764
* testsuite/ld-aarch64/emit-relocs-258.s: Define symbol as an address.
* testsuite/ld-aarch64/emit-relocs-259.s: Likewise.
* testsuite/ld-aarch64/aarch64-elf.exp: Run new test.
* testsuite/ld-aarch64/pr22764.s: New.
* testsuite/ld-aarch64/pr22764.d: New.

-- 
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/22764] [2.30 Regression] ld fails to link 4.13 and 4.15 kernels on aarch64-linux-gnu

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=22764

--- Comment #14 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by Renlin Li :

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

commit 279b2f94168ee91e02ccd070d27c983fc001fe12
Author: Renlin Li 
Date:   Sat Feb 3 13:18:17 2018 +

[PR22764][LD][AARCH64]Allow R_AARCH64_ABS16 and R_AARCH64_ABS32 against
absolution symbol or undefine symbol in shared object.

The assumption that R_AARCH64_ABS16 and R_AARCH64_ABS32 relocation in LP64
abi
will be used to generate an address does not hold for absolute symbol.
In this case, it is a value fixed at static linking time.

The condition to check the relocations is relax to allow absolute symbol
and
undefined symbol case.

bfd/

2018-02-05  Renlin Li  

PR ld/22764
* elfnn-aarch64.c (elfNN_aarch64_check_relocs): Relax the
R_AARCH64_ABS32 and R_AARCH64_ABS16 for absolute symbol. Apply the
check for writeable section as well.

ld/

2018-02-05  Renlin Li  

PR ld/22764
* testsuite/ld-aarch64/emit-relocs-258.s: Define symbol as an address.
* testsuite/ld-aarch64/emit-relocs-259.s: Likewise.
* testsuite/ld-aarch64/aarch64-elf.exp: Run new test.
* testsuite/ld-aarch64/pr22764.s: New.
* testsuite/ld-aarch64/pr22764.d: New.

-- 
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/22782] ld.bfd large static binaries

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22782

--- Comment #4 from H.J. Lu  ---
Fixed for 2.31.

-- 
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/22782] ld.bfd large static binaries

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=22782

--- Comment #3 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=cd04836359da82ae1dc67e5a05565536f4427b51

commit cd04836359da82ae1dc67e5a05565536f4427b51
Author: H.J. Lu 
Date:   Mon Feb 5 08:38:16 2018 -0800

x86: Remove the unused _GLOBAL_OFFSET_TABLE_

Since _GLOBAL_OFFSET_TABLE_ may be referenced implicitly on x86,
checking ref_regular_nonweak leaves the unused _GLOBAL_OFFSET_TABLE_
in output.  This patch checks explicit GOT references instead.

ld-i386/discarded1.s and ld-x86-64/discarded1.s are updated to avoid
linker optimization which removes GOT references.

bfd/

PR ld/22782
* elf32-i386.c (elf_i386_check_relocs): Set got_referenced if
_GLOBAL_OFFSET_TABLE_ is referenced or GOT is needed to resolve
undefined weak symbol to 0.
* elf64-x86-64.c (elf_x86_64_check_relocs): Set got_referenced
if _GLOBAL_OFFSET_TABLE_ is referenced.
* elfxx-x86.c (_bfd_x86_elf_size_dynamic_sections): Check
got_referenced instead of ref_regular_nonweak.  Remove the
unused _GLOBAL_OFFSET_TABLE_ from symbol table.
* elfxx-x86.h (elf_x86_link_hash_table): Add got_referenced.

ld/

PR ld/22782
* testsuite/ld-i386/discarded1.s: Replace mov with div.
* testsuite/ld-x86-64/discarded1.s: Likewise.
* testsuite/ld-i386/i386.exp: Run pr22782.
* testsuite/ld-i386/load1-nacl.d: Updated for removing
_GLOBAL_OFFSET_TABLE_ from output.
* testsuite/ld-i386/load1.d: Likewise.
* testsuite/ld-x86-64/load1a-nacl.d: Likewise.
* testsuite/ld-x86-64/load1a.d: Likewise.
* testsuite/ld-x86-64/load1b-nacl.d: Likewise.
* testsuite/ld-x86-64/load1b.d: Likewise.
* testsuite/ld-i386/pr22782.d: New file.
* testsuite/ld-i386/pr22782.s: Likewise.
* testsuite/ld-x86-64/pr22782.s: Likewise.
* testsuite/ld-x86-64/pr22782a.d: Likewise.
* testsuite/ld-x86-64/pr22782b.d: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Run pr22782a and pr22782b.

-- 
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/22771] nm does not display line information for uninlined copies of functions

[pcarroll at codesourcery dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22771

--- Comment #1 from Paul Carroll  ---
Just to reduce possible confusion, when my previous comment says:

If that test case is compiled and then ...

I am implying

If that test case is compiled with -O2 and then ...

The '-O2' option is needed so inlining occurs.

-- 
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/22789] addr2line can't determine function names in mips binaries compiled with -gline-tables-only

[milos.stojano...@rt-rk.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22789

--- Comment #1 from Miloš Stojanović  ---
This patch should solves it. Added additional check to see if function name was
retrieved successfully, if not, a call is made to function that retrieves it.
Solution is taken from generic _bfd_elf_find_nearest_line function from elf.c.

diff --git a/bfd/elfxx-mips.c b/bfd/elfxx-mips.c
index 285401367d..feed1f4928 100644
--- a/bfd/elfxx-mips.c
+++ b/bfd/elfxx-mips.c
@@ -12655,15 +12655,18 @@ _bfd_mips_elf_find_nearest_line (bfd *abfd, asymbol
**symbols,
   if (_bfd_dwarf2_find_nearest_line (abfd, symbols, NULL, section, offset,
 filename_ptr, functionname_ptr,
 line_ptr, discriminator_ptr,
-dwarf_debug_sections,
-ABI_64_P (abfd) ? 8 : 0,
-_tdata (abfd)->dwarf2_find_line_info))
-return TRUE;
-
-  if (_bfd_dwarf1_find_nearest_line (abfd, symbols, section, offset,
-filename_ptr, functionname_ptr,
-line_ptr))
-return TRUE;
+dwarf_debug_sections,ABI_64_P (abfd) ? 8 :
0,
+_tdata (abfd)->dwarf2_find_line_info)
+  || _bfd_dwarf1_find_nearest_line (abfd, symbols, section, offset,
+   filename_ptr, functionname_ptr,
+   line_ptr))
+{
+  if (!*functionname_ptr)
+   _bfd_elf_find_function (abfd, symbols, section, offset,
+   *filename_ptr ? NULL : filename_ptr,
+   functionname_ptr);
+  return TRUE;
+}

   msec = bfd_get_section_by_name (abfd, ".mdebug");
   if (msec != NULL)

-- 
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/22789] addr2line can't determine function names in mips binaries compiled with -gline-tables-only

[milos.stojano...@rt-rk.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22789

Miloš Stojanović  changed:

   What|Removed |Added

 CC||ma...@linux-mips.org,
   ||milos.stojano...@rt-rk.com,
   ||mips32r2 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 binutils/22789] New: addr2line can't determine function names in mips binaries compiled with -gline-tables-only

[milos.stojano...@rt-rk.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22789

Bug ID: 22789
   Summary: addr2line can't determine function names in mips
binaries compiled with -gline-tables-only
   Product: binutils
   Version: unspecified
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: milos.stojano...@rt-rk.com
  Target Milestone: ---

Created attachment 10785
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10785=edit
Example files

In the attachment are simple binaries compiled on mips64el. The 3 examples are
compiledusing llvm with -g, -gline-tables-only and without additional flags.
When addr2line is used to fetch function names it only fails on the file
compiled with -gline-tables-only:

$ addr2line 12a40 -f -e simple_test
main
??:?
$ addr2line 12a40 -f -e simple_g_test
main
/home/compiler-qa/llvm/simple_gline_test.c:2
$ addr2line 12a40 -f -e simple_gline_test
??
/home/compiler-qa/llvm/simple_gline_test.c:2



The llvm-symbolizer doesn't have the same issue:

$ echo simple_test 0x12a40 | llvm-symbolizer
main
??:0:0

$ echo simple_g_test 0x12a40 | llvm-symbolizer
main
/home/compiler-qa/llvm/simple_gline_test.c:2:0

$ echo simple_gline_test 0x12a40 | llvm-symbolizer
main
/home/compiler-qa/llvm/simple_gline_test.c:2:0



There is no difference with big-endian and mips32 binaries.

-- 
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/22764] [2.30 Regression] ld fails to link 4.13 and 4.15 kernels on aarch64-linux-gnu

[renlin.li at arm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22764

--- Comment #13 from Renlin Li  ---
(In reply to Arnd Bergmann from comment #11)
> I did some more testing with binutils-2.30 on arm64 randconfig kernels. One
> major issue I came across was CONFIG_MODVERSIONS, which causes an error for
> each exported symbol.
> 
...
> While changing one of the .S files, I also ran into a linker crash:
> 
>  aarch64-linux-ld: arch/arm64/kernel/head.o: relocation R_AARCH64_ABS32
> against `__rela_offset' can not be used when making a shared object
> 11:39 PM cross-gcc/bin/aarch64-linux-ld: BFD (GNU Binutils) 2.30 internal
> error, aborting at /home/arnd/git/binutils/bfd/elfnn-aarch64.c:5279 in
> elf64_aarch64_final_link_relocate
> 11:40 PM aarch64-linux-ld: Please report this bug.
> 
> This evidently was caused by the same two instructions that came up earlier:
> 
>ldr w9, =__rela_offset  // offset to reloc table
>ldr w10, =__rela_size   // size of reloc table
> 
> After commenting these out, I got no further crashes.

Hi Arnd,

I could not reproduce the linker crash you described here.
Do you have a minimum testcase for this issues?

Thanks!

-- 
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/22764] [2.30 Regression] ld fails to link 4.13 and 4.15 kernels on aarch64-linux-gnu

[renlin.li at arm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22764

--- Comment #12 from Renlin Li  ---
Hi all,

Sorry for the break. I sent a patch to the mailing list to fix this issue.
https://sourceware.org/ml/binutils/2018-02/msg00039.html

Could you help to check whether it fixes the problem?
Thanks!

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

[hizhangsword at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22788

Bug ID: 22788
   Summary: AddressSanitizer: SEGV
/home/ubuntu/binutils/binutils_git/binutils-gdb/bfd/li
bbfd.c:558 bfd_getl32
   Product: binutils
   Version: 2.30
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: hizhangsword at gmail dot com
  Target Milestone: ---

Created attachment 10784
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10784=edit
the crafted file generated by afl

A crafted elf file can lead SEGV in
function:/binutils/binutils_git/binutils-gdb/bfd/libbfd.c:558 bfd_getl32;
The crafted elf file was found by fuzzing tool:afl;
Tests in version 2.30 and commit 0eb876f52f348ff08be24bca6cbca00e302839b2 both
worked；

root@ubuntu:/home/ubuntu/binutils/binutils_git/binutils-gdb# binutils/objdump
-x crashes/id:25,sig:06,src:72,op:int32,pos:6216,val:be:+16
ASAN:SIGSEGV
=
==869==ERROR: AddressSanitizer: SEGV on unknown address 0x14500b88 (pc
0x08275e3b bp 0x14500b8b sp 0xffe1f7a0 T0)
#0 0x8275e3a in bfd_getl32
/home/ubuntu/binutils/binutils_git/binutils-gdb/bfd/libbfd.c:558
#1 0x83499b5 in elf_parse_notes
/home/ubuntu/binutils/binutils_git/binutils-gdb/bfd/elf.c:11024
#2 0x836d9a1 in _bfd_elf_make_section_from_shdr
/home/ubuntu/binutils/binutils_git/binutils-gdb/bfd/elf.c:1098
#3 0x8361481 in _bfd_elf_make_section_from_shdr
/home/ubuntu/binutils/binutils_git/binutils-gdb/bfd/elf.c:988
#4 0x8361481 in bfd_section_from_shdr
/home/ubuntu/binutils/binutils_git/binutils-gdb/bfd/elf.c:2443
#5 0x85575dd in bfd_elf32_object_p
/home/ubuntu/binutils/binutils_git/binutils-gdb/bfd/elfcode.h:805
#6 0x826abfb in bfd_check_format_matches
/home/ubuntu/binutils/binutils_git/binutils-gdb/bfd/format.c:311
#7 0x806af3e in display_object_bfd objdump.c:3663
#8 0x806af3e in display_any_bfd objdump.c:3754
#9 0x8056dab in display_file objdump.c:3775
#10 0x8056dab in main objdump.c:4077
#11 0xf70a7636 in __libc_start_main (/lib32/libc.so.6+0x18636)
#12 0x8059cfb 
(/home/ubuntu/binutils/binutils_git/binutils-gdb/binutils/objdump+0x8059cfb)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV
/home/ubuntu/binutils/binutils_git/binutils-gdb/bfd/libbfd.c:558 bfd_getl32
==869==ABORTING
root@ubuntu:/home/ubuntu/binutils/binutils_git/binutils-gdb# git show
commit 0eb876f52f348ff08be24bca6cbca00e302839b2

The crafted file please check the attachement；
Please forgive me for my bad english，^_^

-- 
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/22764] [2.30 Regression] ld fails to link 4.13 and 4.15 kernels on aarch64-linux-gnu

[arnd at arndb dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=22764

Arnd Bergmann  changed:

   What|Removed |Added

 CC||arnd at arndb dot de

--- Comment #11 from Arnd Bergmann  ---
I did some more testing with binutils-2.30 on arm64 randconfig kernels. One
major issue I came across was CONFIG_MODVERSIONS, which causes an error for
each exported symbol.

aarch64-linux-ld: init/main.o: relocation R_AARCH64_ABS32 against
`__crc_system_state' can not be used when making a shared object
aarch64-linux-ld: init/version.o: relocation R_AARCH64_ABS32 against
`__crc_init_uts_ns' can not be used when making a shared object
aarch64-linux-ld: init/do_mounts.o: relocation R_AARCH64_ABS32 against
`__crc_name_to_dev_t' can not be used when making a shared object
aarch64-linux-ld: init/init_task.o: relocation R_AARCH64_ABS32 against
`__crc_init_task' can not be used when making a shared object
aarch64-linux-ld: arch/arm64/kernel/fpsimd.o: relocation R_AARCH64_ABS32
against `__crc_kernel_neon_busy' can not be used when making a shared object
aarch64-linux-ld: arch/arm64/kernel/process.o: relocation R_AARCH64_ABS32
against `__crc___stack_chk_guard' can not be used when making a shared object
aarch64-linux-ld: arch/arm64/kernel/stacktrace.o: relocation R_AARCH64_ABS32
against `__crc_save_stack_trace_tsk' can not be used when making a shared
object


While changing one of the .S files, I also ran into a linker crash:

 aarch64-linux-ld: arch/arm64/kernel/head.o: relocation R_AARCH64_ABS32 against
`__rela_offset' can not be used when making a shared object
11:39 PM cross-gcc/bin/aarch64-linux-ld: BFD (GNU Binutils) 2.30 internal
error, aborting at /home/arnd/git/binutils/bfd/elfnn-aarch64.c:5279 in
elf64_aarch64_final_link_relocate
11:40 PM aarch64-linux-ld: Please report this bug.

This evidently was caused by the same two instructions that came up earlier:

   ldr w9, =__rela_offset  // offset to reloc table
   ldr w10, =__rela_size   // size of reloc table

After commenting these out, I got no further crashes.

-- 
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/22762] missing static variable constructor calls

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=22762

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

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

commit a985e9b9deabd81e16754584f4397a638e9d3f36
Author: Nick Clifton 
Date:   Mon Feb 5 09:12:42 2018 +

Import patch from mainline to remove PROVODE qualifiers around definitions
of __CTOR_LIST__ and __DTOR_LIST__ in PE linker scripts.

PR 22762
* scripttempl/pe.sc: Remove PROVIDE()s from __CTOR_LIST__ and
__DTOR_LIST__ symbols.  Add a comment explaining why this is
necessary.
* scripttemp/pep.sc: Likewise.
* ld.texinfo (PROVIDE): Add a note about the effect of common
symbols.

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