[Bug ld/22846] i686-w64-mingw32 cross linker generates truncated binary image

2018-02-15 Thread despair at rvx86 dot net
https://sourceware.org/bugzilla/show_bug.cgi?id=22846

--- Comment #3 from Absolute Despair  ---
Created attachment 10824
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10824=edit
bad executable

-- 
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/22846] i686-w64-mingw32 cross linker generates truncated binary image

2018-02-15 Thread despair at rvx86 dot net
https://sourceware.org/bugzilla/show_bug.cgi?id=22846

--- Comment #2 from Absolute Despair  ---
Created attachment 10823
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10823=edit
bad shared object

-- 
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/22845] -z separate-code doesn't work right

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

--- Comment #4 from H.J. Lu  ---
FAIL: ld-elf/eh4

[hjl@gnu-tools-1 ld]$
/export/build/gnu/binutils/build-x86_64-linux/ld/../gas/as-new  --defsym
ALIGN=3 --64  -o tmpdir/eh4.o
/export/gnu/import/git/sources/binutils-gdb/ld/testsuite/ld-elf/eh4.s
[hjl@gnu-tools-1 ld]$
/export/build/gnu/binutils/build-x86_64-linux/ld/../gas/as-new  --defsym
ALIGN=3 --64  -o tmpdir/eh4a.o
/export/gnu/import/git/sources/binutils-gdb/ld/testsuite/ld-elf/eh4a.s
[hjl@gnu-tools-1 ld]$ ld -z separate-code  -z norelro 
-L/export/gnu/import/git/sources/binutils-gdb/ld/testsuite/ld-elf  -melf_x86_64
-shared -Ttext 0x400 -o tmpdir/dump tmpdir/eh4.o tmpdir/eh4a.o 
ld: section .eh_frame LMA [0020,00200073] overlaps section
.plt LMA [0020,0020001f]
[hjl@gnu-tools-1 ld]$ 

-Ttext 0x400 doesn't work with -z separate-code.

-- 
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/22846] i686-w64-mingw32 cross linker generates truncated binary image

2018-02-15 Thread despair at rvx86 dot net
https://sourceware.org/bugzilla/show_bug.cgi?id=22846

--- Comment #4 from Absolute Despair  ---
It also silently fails when linking executable images:

/* test.c */
#include 

main(argc, argv)
char **argv;
{
puts("hi bugzilla");
return 0;
}

compile with:
i686-w64-mingw32-gcc test.c -o test.exe
or
i686-w64-mingw32-clang test.c -o test.exe

(Since Clang is also the system compiler on my platform, I manually renamed the
Clang cross-compiler after building it.)

-- 
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/22846] i686-w64-mingw32 cross linker generates truncated binary image

2018-02-15 Thread despair at rvx86 dot net
https://sourceware.org/bugzilla/show_bug.cgi?id=22846

--- Comment #1 from Absolute Despair  ---
Created attachment 10822
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10822=edit
truncated IAT/GOT

-- 
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-15 Thread ro at CeBiTec dot Uni-Bielefeld.DE
https://sourceware.org/bugzilla/show_bug.cgi?id=13671

--- Comment #22 from Rainer Orth  ---
> --- Comment #21 from H.J. Lu  ---
[...]
> I didn't see R_386_TLS_TPOFF.  What happened to
>
> 0030  0b12 R_386_TLS_GD   0004  
> __gcov_indirect_call_callee
>
> in input file?

This:

_gcov_indirect_call_profiler_v2.o has

  1a:   8d 04 1d 00 00 00 00lea0x0(,%ebx,1),%eax
  21:   e8 fc ff ff ff  call   22
<__gcov_indirect_call_profiler_v2+0x22>

with the R_386_TLS_GD reloc above; the executable has

 805224a:   65 a1 00 00 00 00   mov%gs:0x0,%eax
 8052250:   05 fc ff ff ff  add$0xfffc,%eax
 8052255:   90  nop

without any relocs.

Btw., please note that I'll be on an extended vacation starting
tomorrow, with little or no net access for a month.

-- 
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/22832] 2.30 internal error, aborting at ../../bfd/elflink.c:9710 in elf_link_output_extsym

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

--- Comment #8 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by Eric Botcazou :

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

commit e513bd38a6b91401947d90ba5f301f01d3991b8e
Author: Eric Botcazou 
Date:   Thu Feb 15 15:55:11 2018 +0100

PR ld/22832 on SPARC.

The fix for PR ld/22727 on SPARC passed TRUE as the 'create' argument
in the call to bfd_link_hash_lookup.  It turns out this was a bad idea
because, if the symbol is created at this point, the link will abort
later in elf_link_output_extsym.  This changes the TRUE into a FALSE
and puts an assertion on the result of the call, making it easier to
debug the issue; that's exactly in keeping with what Gold does.

bfd/
* elfxx-sparc.c (_bfd_sparc_elf_check_relocs) :
Pass FALSE instead of TRUE as 'create' argument to bfd_link_hash_lookup
and assert that the result of the call is not 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 ld/22727] [2.30, 2.31 regression] Thousands of EH-related execution failures on SPARC

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

--- Comment #22 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by Eric Botcazou :

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

commit e513bd38a6b91401947d90ba5f301f01d3991b8e
Author: Eric Botcazou 
Date:   Thu Feb 15 15:55:11 2018 +0100

PR ld/22832 on SPARC.

The fix for PR ld/22727 on SPARC passed TRUE as the 'create' argument
in the call to bfd_link_hash_lookup.  It turns out this was a bad idea
because, if the symbol is created at this point, the link will abort
later in elf_link_output_extsym.  This changes the TRUE into a FALSE
and puts an assertion on the result of the call, making it easier to
debug the issue; that's exactly in keeping with what Gold does.

bfd/
* elfxx-sparc.c (_bfd_sparc_elf_check_relocs) :
Pass FALSE instead of TRUE as 'create' argument to bfd_link_hash_lookup
and assert that the result of the call is not 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 ld/22832] 2.30 internal error, aborting at ../../bfd/elflink.c:9710 in elf_link_output_extsym

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

--- Comment #9 from cvs-commit at gcc dot gnu.org  ---
The binutils-2_30-branch branch has been updated by Eric Botcazou
:

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

commit d31b3bc9174ca62d7527a63e6428718311faff9c
Author: Eric Botcazou 
Date:   Thu Feb 15 15:55:11 2018 +0100

PR ld/22832 on SPARC.

The fix for PR ld/22727 on SPARC passed TRUE as the 'create' argument
in the call to bfd_link_hash_lookup.  It turns out this was a bad idea
because, if the symbol is created at this point, the link will abort
later in elf_link_output_extsym.  This changes the TRUE into a FALSE
and puts an assertion on the result of the call, making it easier to
debug the issue; that's exactly in keeping with what Gold does.

bfd/
* elfxx-sparc.c (_bfd_sparc_elf_check_relocs) :
Pass FALSE instead of TRUE as 'create' argument to bfd_link_hash_lookup
and assert that the result of the call is not 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 ld/22727] [2.30, 2.31 regression] Thousands of EH-related execution failures on SPARC

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

--- Comment #23 from cvs-commit at gcc dot gnu.org  ---
The binutils-2_30-branch branch has been updated by Eric Botcazou
:

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

commit d31b3bc9174ca62d7527a63e6428718311faff9c
Author: Eric Botcazou 
Date:   Thu Feb 15 15:55:11 2018 +0100

PR ld/22832 on SPARC.

The fix for PR ld/22727 on SPARC passed TRUE as the 'create' argument
in the call to bfd_link_hash_lookup.  It turns out this was a bad idea
because, if the symbol is created at this point, the link will abort
later in elf_link_output_extsym.  This changes the TRUE into a FALSE
and puts an assertion on the result of the call, making it easier to
debug the issue; that's exactly in keeping with what Gold does.

bfd/
* elfxx-sparc.c (_bfd_sparc_elf_check_relocs) :
Pass FALSE instead of TRUE as 'create' argument to bfd_link_hash_lookup
and assert that the result of the call is not 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 ld/22832] internal error, aborting at ../../bfd/elflink.c:9710 in elf_link_output_extsym

2018-02-15 Thread ebotcazou at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=22832

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX
   Target Milestone|--- |2.31
Summary|2.30 internal error,|internal error, aborting at
   |aborting at |../../bfd/elflink.c:9710 in
   |../../bfd/elflink.c:9710 in |elf_link_output_extsym
   |elf_link_output_extsym  |

--- Comment #10 from Eric Botcazou  ---
BFD adjusted, the assertion failure is now similar to that of Gold.

-- 
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/22840] Several TLS tests FAIL on Solaris/SPARC

2018-02-15 Thread ebotcazou at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=22840

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #1 from Eric Botcazou  ---
>   Unfortunately, unlike the #ld: lines in the *.?d files which can be
>   modified by setting options_regsub(ld) for perform the appropriate 
>   substitution, this is not currently possible for the arg to 
>   run_ld_link_tests.

Can't we use a variable EMULATION or some such?

> * To make some progress, I've hardcoded the Solaris values for now, which
> leads me to the next issues:
> 
>   The file format lines in the *.?d files under test all hardcode elf32-sparc
>   or elf64-sparc, but should allow for elf32-sparc-sol2 (resp.
> elf32-sparc.*).
>
> * Even with that fixed, there are many failures due to the fact that the
> Solaris
>   ABI requires a couple of additional symbols (cf. emultempl/solaris2.em
>   (elf_solaris2_before_allocation), and those aren't currently expected in
>   the output.  I'm uncertain how best to handle that: allow for a
> postprocessing
>   step after readelf that removes those from the output or augment the
> expected
>   output accordingly?  It seems regexp_diff currently has no support for
>   optional or target-specific lines in the expected output.

Can't we have specific *.?d files 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 ld/22758] FAIL: Run pr22393-2

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

--- Comment #8 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=355d8ed79b1e830d5216a70026f751f5a38df9e9

commit 355d8ed79b1e830d5216a70026f751f5a38df9e9
Author: Nick Clifton 
Date:   Thu Feb 15 16:21:02 2018 +

Import patch from mainline to fix a bug that would place executable and
non-executables pages in the same segment.

PR 22758
bfd * elf.c (_bfd_elf_map_sections_to_segments): Don't start a new
segment when demand paged with lma on the same page.  Test this
before load/non-load, executable/non-executable,
writable/non-writable tests and simplify.  Delete bogus relro
condition in writable/non-writable test.  Delete outdated
comment.  Formatting.

-- 
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/22758] FAIL: Run pr22393-2

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

--- Comment #9 from Nick Clifton  ---
(In reply to Romain Geissler from comment #7)

> Given that this
> might potentially happen arbitrarily to any user of binutils 2.30 and it is
> not so easy to understand that section placement is wrong here, would you
> please backport this to the 2.30 branch ?

Done.

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