date:20151001

[Bug ld/19013] Section corrupted with elf64-x86-64 input -> elf32-i386 output

2015-10-01 Thread cvs-commit at gcc dot gnu.org

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

--- Comment #7 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=017e6bceee1a96d4b57175687560b4d625fdb150

commit 017e6bceee1a96d4b57175687560b4d625fdb150
Author: Alan Modra 
Date:   Thu Oct 1 07:38:07 2015 +0930

Revert "Also check e_machine when merging sections"

Commit 9865bd0d added a bogus check in _bfd_elf_merge_sections.

bfd/
PR ld/19013
* elflink.c (_bfd_elf_merge_sections): Revert last change.
ld/testsuite/
* ld-x86-64/pr19013-x32.d: Update.

-- 
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/19030] ld generates .so/x86 with bad phdr so the Android linker won't dlopen

2015-10-01 Thread winter-...@bfw-online.de

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

--- Comment #2 from winter-...@bfw-online.de ---
Your analysis is correct, thank you.

While "-nostdlib" actually is a ld option (at least in my ld according to
--help and man page), I rechecked and noticed I passed another gcc parameter
"-no-enum-size-warning" to ld which seems to behave like "-n" as you suggested
hence you can label this as user error but I keep wondering how this parameter
handling could be useful/intended.

The man page says "For options whose names are a single letter, option
arguments must either follow the option letter without intervening whitespace,
or be given as separate arguments immediately following the option that
requires them." so "-no-enum-size-warning" would be taken as "-n" with value
"o-enum-size-warning". Yet according to the man page "-n" does not take a
value, so it seems the trailing characters will be silently discarded.

Is this parameter-handling behavior intended this way? (Should one open a new
bug to discuss that?)

-- 
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/19030] ld generates .so/x86 with bad phdr so the Android linker won't dlopen

2015-10-01 Thread amodra at gmail dot com

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

Alan Modra  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||amodra at gmail dot com
 Resolution|--- |INVALID

--- Comment #1 from Alan Modra  ---
-nostdlib is a gcc option, not a ld option.  It looks to me like your version
of ld is treating the option as if it were -n.

-- 
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/19030] ld generates .so/x86 with bad phdr so the Android linker won't dlopen

2015-10-01 Thread winter-...@bfw-online.de

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

--- Comment #3 from winter-...@bfw-online.de ---
Even worse, the actual error is the missing dash in the beginning.
"--no-enum-size-warning" *is* a ld parameter but without the first dash it
behaves like "-n".

-- 
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/1198] Segfault when executing objdump on a special file...

2015-10-01 Thread sch...@linux-m68k.org

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #2 from Andreas Schwab  ---
Does that still happen with the latest version?

-- 
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/4897] [regression] failing testcases on m68k-linux-gnu

2015-10-01 Thread sch...@linux-m68k.org

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at sources dot redhat.c |unassigned at 
sourceware dot org
   |om  |

--- Comment #1 from Andreas Schwab  ---
None of these tests fail any more, closing as 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 binutils/1298] m68k-dis.c:1348: warning: argument 'info' might be clobbered by 'longjmp' or 'vfork'

2015-10-01 Thread sch...@linux-m68k.org

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |OBSOLETE

--- Comment #4 from Andreas Schwab  ---
The gcc bug is fixed in all supported gcc versions.

-- 
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 gas/11030] Missing opcode for assembly instruction 'stldsr' in isa aplus of m68k assembler

2015-10-01 Thread sch...@linux-m68k.org

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |2.23

--- Comment #6 from Andreas Schwab  ---
Fixed in 2.20.

-- 
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/19042] New: unsupported reloc 311/312

2015-10-01 Thread sch...@linux-m68k.org

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

Bug ID: 19042
   Summary: unsupported reloc 311/312
   Product: binutils
   Version: 2.26 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: gold
  Assignee: ccoutant at gmail dot com
  Reporter: sch...@linux-m68k.org
CC: ian at airs dot com
  Target Milestone: ---
Target: aarch64-*-*

$ make check-gold
[...]
`echo gcc -DHAVE_CONFIG_H -I. -I../../../binutils/gold/testsuite -I.. 
-I../../../binutils/gold/testsuite -I../../../binutils/gold/testsuite/..
-I../../../binutils/gold/testsuite/../../include
-I../../../binutils/gold/testsuite/../../elfcpp -I..
-DLOCALEDIR="\"/usr/share/locale\""   -W -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wshadow -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-fmerge-constants -O2 -g | sed -e 's/-Wp,-D_FORTIFY_SOURCE=[0-9[0-9]]*//'` -c
-fPIC -o ifuncmain7pic.o ../../../binutils/gold/testsuite/ifuncmain7.c
`echo gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fmerge-constants -O2 -g
-fno-use-linker-plugin   -o ifuncmain7picstatic | sed -e
's/-Wp,-D_FORTIFY_SOURCE=[0-9][0-9]*//'` -Bgcctestdir/ -static ifuncmain7pic.o
gcctestdir/ld: error: ifuncmain7pic.o: unsupported reloc 311 against local
symbol
gcctestdir/ld: error: ifuncmain7pic.o: unsupported reloc 312 against local
symbol
gcctestdir/ld: error: ifuncmain7pic.o: unsupported reloc 311 against local
symbol
gcctestdir/ld: error: ifuncmain7pic.o: unsupported reloc 312 against local
symbol
gcctestdir/ld: internal error in relocate, at
../../binutils/gold/aarch64.cc:5669
collect2: error: ld returned 1 exit status
Makefile:5571: recipe for target 'ifuncmain7picstatic' failed
make[4]: *** [ifuncmain7picstatic] Error 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/18995] c++filt segfault on line not containing a symbol

2015-10-01 Thread nickc at redhat dot com

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

Nick Clifton  changed:

   What|Removed |Added

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

--- Comment #3 from Nick Clifton  ---
Ian is correct, his patch does fix this problem.

I have now brought in Ian's patch from the gcc repository and checked it in to
the binutils repository.

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 gold/19044] New: Gold links single-threaded program into a deadlock on i686 Linux

2015-10-01 Thread sduvan.gcc at gmail dot com

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

Bug ID: 19044
   Summary: Gold links single-threaded program into a deadlock on
i686 Linux
   Product: binutils
   Version: 2.25
Status: NEW
  Severity: normal
  Priority: P2
 Component: gold
  Assignee: ccoutant at gmail dot com
  Reporter: sduvan.gcc at gmail dot com
CC: ian at airs dot com
  Target Milestone: ---

Created attachment 8664
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8664=edit
Testcase

The attached reduced testcase shows an example where single-threaded code, if
compiled with gcc 5.2.0 and linked with gold (version 2.25) on i686 Linux,
results in an executable that deadlocks when run. Looking into the details with
a debugger, it seems like the threaded mode support code in libstdc++
(__gthread_active_p()) is handled differently in the constructor and the
destructor of __gnu_cxx::___scoped_lock. While the constructor does the
appropriate test the destructor does not (equivalent to assuming no threading
support). This means that the second time __scoped_lock's constructor is called
the program deadlocks.

Linking with ld (version 2.25), there is no deadlock. Compiling and linking
with gold on x86_64 does not result in a deadlock. The testcase is sensitive to
perturbations and compiler version (the issue has also been seen with gcc 4.9.1
but the testcase was much bigger in that case).

gcc 5.2.0 was configured in the following way:

bash> /opt/sandbox/gcc/5.2.0/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/opt/sandbox/gcc/5.2.0/bin/g++
COLLECT_LTO_WRAPPER=/opt/sandbox/gcc/5.2.0/lib/gcc/x86_64-suse-linux/5.2.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../../gcc-5.2.0/configure --enable-languages=c,c++,fortran
--enable-targets=x86_64-suse-linux,i686-suse-linux
--prefix=/opt/sandbox/gcc/5.2.0 --with-gnu-as
--with-as=/opt/sandbox/gcc/binutils-2.25.1/bin/as --with-gnu-ld
--with-ld=/opt/sandbox/gcc/binutils-2.25.1/bin/ld.gold
--with-gmp=/opt/sandbox/gcc/gmp-5.0.1 --with-mpfr=/opt/sandbox/gcc/mpfr-3.0.0
--with-mpc=/opt/sandbox/gcc/mpc-0.8.2 --enable-threads=posix --enable-shared
--enable-__cxa_atexit --enable-libstdcxx-allocator=pool x86_64-suse-linux
Thread model: posix
gcc version 5.2.0 (GCC)

To see the deadlock:
bash> tar -zxvf gold-bug.tar.gz
bash> make bug
bash> ./bug
(hangs)

-- 
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/19030] ld generates .so/x86 with bad phdr so the Android linker won't dlopen

2015-10-01 Thread ian at airs dot com

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #4 from Ian Lance Taylor  ---
The option -no-enum-size-warning is handled as -n -o -enum-size-warning.  In
other words, the -n option, followed by the -o option, setting the name of the
output file to -enum-size-warning.  Perhaps in your case you had a subsequent
-o option setting a different output file name--that last -o option on the
command line takes precedence.

Yes, one dash or two makes a difference.

-- 
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/19041] New: unsupported TLSLE reloc 549/551

2015-10-01 Thread sch...@linux-m68k.org

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

Bug ID: 19041
   Summary: unsupported TLSLE reloc 549/551
   Product: binutils
   Version: 2.26 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: gold
  Assignee: ccoutant at gmail dot com
  Reporter: sch...@linux-m68k.org
CC: ian at airs dot com
  Target Milestone: ---
Target: aarch64-*-*

$ make check-gold
[...]
`echo g++ -DHAVE_CONFIG_H -I. -I../../../binutils/gold/testsuite -I.. 
-I../../../binutils/gold/testsuite -I../../../binutils/gold/testsuite/..
-I../../../binutils/gold/testsuite/../../include
-I../../../binutils/gold/testsuite/../../elfcpp -I..
-DLOCALEDIR="\"/usr/share/locale\""   -W -Wall-D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -fmerge-constants -O2 -g | sed -e
's/-Wp,-D_FORTIFY_SOURCE=[0-9][0-9]*//'` -MT tls_test.o -MD -MP -MF
.deps/tls_test.Tpo -c -o tls_test.o
../../../binutils/gold/testsuite/tls_test.cc
[...]
`echo g++ -W -Wall-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-fmerge-constants -O2 -g -fno-use-linker-plugin   -o tls_test_shared_nonpic.so
| sed -e 's/-Wp,-D_FORTIFY_SOURCE=[0-9][0-9]*//'` -Bgcctestdir/ -shared
tls_test.o tls_test_file2.o tls_test_c.o -Wl,-z,notext
gcctestdir/ld: error: tls_test.o: unsupported TLSLE reloc 549 in shared code.
gcctestdir/ld: error: tls_test.o: unsupported TLSLE reloc 551 in shared code.
gcctestdir/ld: error: tls_test.o: unsupported TLSLE reloc 549 in shared code.
gcctestdir/ld: error: tls_test.o: unsupported TLSLE reloc 551 in shared code.
gcctestdir/ld: error: tls_test.o: unsupported TLSLE reloc 549 in shared code.
gcctestdir/ld: error: tls_test.o: unsupported TLSLE reloc 551 in shared code.
gcctestdir/ld: error: tls_test.o: unsupported TLSLE reloc 549 in shared code.
gcctestdir/ld: error: tls_test.o: unsupported TLSLE reloc 551 in shared code.
gcctestdir/ld: error: tls_test.o: unsupported TLSLE reloc 549 in shared code.
gcctestdir/ld: error: tls_test.o: unsupported TLSLE reloc 551 in shared code.
gcctestdir/ld: error: tls_test.o: unsupported TLSLE reloc 549 in shared code.
gcctestdir/ld: error: tls_test.o: unsupported TLSLE reloc 551 in shared code.
gcctestdir/ld: error: tls_test.o: unsupported TLSLE reloc 549 in shared code.
gcctestdir/ld: error: tls_test.o: unsupported TLSLE reloc 551 in shared code.
gcctestdir/ld: error: tls_test.o: unsupported TLSLE reloc 549 in shared code.
gcctestdir/ld: error: tls_test.o: unsupported TLSLE reloc 551 in shared code.
gcctestdir/ld: error: tls_test.o: unsupported TLSLE reloc 549 in shared code.
gcctestdir/ld: error: tls_test.o: unsupported TLSLE reloc 551 in shared code.
gcctestdir/ld: error: tls_test.o: unsupported TLSLE reloc 549 in shared code.
gcctestdir/ld: error: tls_test.o: unsupported TLSLE reloc 551 in shared code.
gcctestdir/ld: error: tls_test.o: unsupported TLSLE reloc 549 in shared code.
gcctestdir/ld: error: tls_test.o: unsupported TLSLE reloc 551 in shared code.
gcctestdir/ld: error: tls_test_c.o: unsupported TLSLE reloc type 549 in shared
objects.
gcctestdir/ld: error: tls_test_c.o: unsupported TLSLE reloc type 551 in shared
objects.
gcctestdir/ld: error: tls_test_c.o: unsupported TLSLE reloc type 549 in shared
objects.
gcctestdir/ld: error: tls_test_c.o: unsupported TLSLE reloc type 551 in shared
objects.
gcctestdir/ld: error: tls_test.o: unsupported reloc 549 in non-static TLSLE
mode.
../../../binutils/gold/testsuite/tls_test.cc:87: error: unexpected opcode while
processing relocation R_AARCH64_TLSLE_ADD_TPREL_HI12
gcctestdir/ld: error: tls_test.o: unsupported reloc 551 in non-static TLSLE
mode.
../../../binutils/gold/testsuite/tls_test.cc:87: error: unexpected opcode while
processing relocation R_AARCH64_TLSLE_ADD_TPREL_LO12_NC
gcctestdir/ld: error: tls_test.o: unsupported reloc 549 in non-static TLSLE
mode.
../../../binutils/gold/testsuite/tls_test.cc:95: error: unexpected opcode while
processing relocation R_AARCH64_TLSLE_ADD_TPREL_HI12
gcctestdir/ld: error: tls_test.o: unsupported reloc 551 in non-static TLSLE
mode.
../../../binutils/gold/testsuite/tls_test.cc:95: error: unexpected opcode while
processing relocation R_AARCH64_TLSLE_ADD_TPREL_LO12_NC
gcctestdir/ld: error: tls_test.o: unsupported reloc 549 in non-static TLSLE
mode.
../../../binutils/gold/testsuite/tls_test.cc:103: error: unexpected opcode
while processing relocation R_AARCH64_TLSLE_ADD_TPREL_HI12
gcctestdir/ld: error: tls_test.o: unsupported reloc 551 in non-static TLSLE
mode.
../../../binutils/gold/testsuite/tls_test.cc:103: error: unexpected opcode
while processing relocation R_AARCH64_TLSLE_ADD_TPREL_LO12_NC
gcctestdir/ld: error: tls_test.o: unsupported reloc 549 in non-static TLSLE
mode.
../../../binutils/gold/testsuite/tls_test.cc:111: error: unexpected opcode
while processing relocation R_AARCH64_TLSLE_ADD_TPREL_HI12
gcctestdir/ld: error: tls_test.o: unsupported reloc 551 in non-static TLSLE
mode.

[Bug gas/14193] mov3q.l followed by movem.l generates illegal instruction on Coldfire 5480 (or -march=cfv4e)

2015-10-01 Thread sch...@linux-m68k.org

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #2 from Andreas Schwab  ---
Fixed in 2.23.

-- 
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/19047] gold --icf vs REL with negative addend

2015-10-01 Thread roland at gnu dot org

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

Roland McGrath  changed:

   What|Removed |Added

   Assignee|ccoutant at gmail 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 gold/19031] R_386_PC32 does not imply a call

2015-10-01 Thread cvs-commit at gcc dot gnu.org

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

--- Comment #5 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=5db4f0d383e3de40e594cf05dd8f6d743233a487

commit 5db4f0d383e3de40e594cf05dd8f6d743233a487
Author: H.J. Lu 
Date:   Thu Oct 1 10:49:33 2015 -0700

Create a PLT entry for R_X86_64_PC32 in non-code sections

Since something like ".long foo - ." may be used as pointer, we make
sure that PLT is used if foo is a function defined in a shared library.

bfd/

PR ld/19031
* elf64-x86-64.c (elf_x86_64_check_relocs): Set
pointer_equality_needed for R_X86_64_PC32 reloc in non-code
sections.

ld/testsuite/

PR ld/19031
* ld-x86-64/x86-64.exp: Run PR ld/19031 test.
* ld-x86-64/pr19031.out: New file.
* ld-x86-64/pr19031a.c: Likewise.
* ld-x86-64/pr19031b.S: Likewise.
* ld-x86-64/pr19031c.c: 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/19047] New: gold --icf vs REL with negative addend

2015-10-01 Thread roland at gnu dot org

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

Bug ID: 19047
   Summary: gold --icf vs REL with negative addend
   Product: binutils
   Version: 2.25
Status: NEW
  Severity: normal
  Priority: P2
 Component: gold
  Assignee: ccoutant at gmail dot com
  Reporter: roland at gnu dot org
CC: ian at airs dot com
  Target Milestone: ---

See https://sourceware.org/ml/binutils/2015-09/msg00243.html

Sriraram is looking into a small reproducer.

-- 
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/19031] R_386_PC32 does not imply a call

2015-10-01 Thread rafael.espindola at gmail dot com

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

--- Comment #4 from Rafael Ávila de Espíndola  ---
Created attachment 8665
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8665=edit
x86_64 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/19042] unsupported reloc 311/312

2015-10-01 Thread ccoutant at gmail dot com

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

Cary Coutant  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|ccoutant at gmail dot com  |shenhan 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 gold/19041] unsupported TLSLE reloc 549/551

2015-10-01 Thread ccoutant at gmail dot com

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

Cary Coutant  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|ccoutant at gmail dot com  |shenhan 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

Can gold's max page size for AArch64 be updated to 64k to match current kernel capabilities?

2015-10-01 Thread Chad Rosier

When attempting to compile and run binaries using recent versions of the
gold linker on AArch64 on a kernel with a 64k page granule, we observe
translation faults before the programs reach main(). When these same
binaries are run on a kernel with a 4k page granule, they run successfully
to completion. We observe that adding '-z max-page-size=0x1' to our
linker flags allows them to run successfully even on a 64k page kernel. We
have also observed the following error when loading shared objects at
runtime on a 64k-page kernel, and suspect it is due to the same issue: 

ELF load command alignment not page-aligned

 

Can gold's max page size for AArch64 be updated to 64k to match current
kernel capabilities?

 

Thanks,

  Chad

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

[Bug gold/19031] R_386_PC32 does not imply a call

2015-10-01 Thread rafael.espindola at gmail dot com

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

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

-- 
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/19031] R_386_PC32 does not imply a call

2015-10-01 Thread hjl.tools at gmail dot com

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

--- Comment #3 from H.J. Lu  ---
(In reply to Rafael Ávila de Espíndola from comment #1)
> Created attachment 8653 [details]
> patch

I don't think it is correct.  See my ld fix:

https://sourceware.org/ml/binutils/2015-09/msg00328.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

[Bug ld/19013] Section corrupted with elf64-x86-64 input -> elf32-i386 output

2015-10-01 Thread cvs-commit at gcc dot gnu.org

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

--- Comment #6 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=9865bd0da6e59c3a1c55605b5a6a9283ed4d542c

commit 9865bd0da6e59c3a1c55605b5a6a9283ed4d542c
Author: H.J. Lu 
Date:   Wed Sep 30 05:32:12 2015 -0700

Also check e_machine when merging sections

When we check consistency for merge ELF sections, we should not only
check EI_CLASS, but also compatible e_machine.

bfd/

PR ld/19013
* elflink.c (_bfd_elf_merge_sections): Only merge input bfds
that have the compatible ELF machine code with the output bfd.

ld/testsuite/

PR ld/19013
* ld-x86-64/pr19013-nacl.d: New file.
* ld-x86-64/pr19013-x32.d: Likewise.
* ld-x86-64/pr19013.d: Likewise.
* ld-x86-64/pr19013.s: Likewise.
* ld-x86-64/x86-64.exp: Run PR ld/19013 tests.

-- 
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/19031] New: R_386_PC32 does not imply a call

2015-10-01 Thread rafael.espindola at gmail dot com

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

Bug ID: 19031
   Summary: R_386_PC32 does not imply a call
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: gold
  Assignee: ccoutant at gmail dot com
  Reporter: rafael.espindola at gmail dot com
CC: amonakov at gmail dot com, bugdal at aerifal dot cx,
hjl.tools at gmail dot com, ian at airs dot com
  Target Milestone: ---

Created attachment 8652
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8652=edit
testcase

In order for function pointer comparisons to work when a non -fPIC non -fPIE
program uses a shared library symbol the static linker has to create an
undefined symbol with a value that points to the plt entry.

Currently both gold and bfd ld assume that R_386_PC32 is a call and therefore
doesn't capture the address, but there is no such guarantee in the psabi.

The attached patch has two functions, g and h. g will get the function address
of f using the GOT. h will get the function address of f using R_386_PC32. If f
is linked in from a .o, both return the same value. If f is linked in from a
.so one gets the body of f and another gets the plt entry.

-- 
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/19031] R_386_PC32 does not imply a call

2015-10-01 Thread cvs-commit at gcc dot gnu.org

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

--- Comment #2 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=4b627c18440f51077f8fd4c18adaa3919c3a373e

commit 4b627c18440f51077f8fd4c18adaa3919c3a373e
Author: H.J. Lu 
Date:   Wed Sep 30 08:32:45 2015 -0700

Create a PLT entry for R_386_PC32 in non-code sections

Since something like ".long foo - ." may be used as pointer, we make
sure that PLT is used if foo is a function defined in a shared library.

bfd/

PR ld/19031
* elf32-i386.c (elf_i386_check_relocs): Set
pointer_equality_needed for R_386_PC32 reloc in non-code
sections.

ld/testsuite/

PR ld/19031
* ld-i386/i386.exp: Run PR ld/19031 test.
* ld/testsuite/ld-i386/pr19031.out: New file.
* ld/testsuite/ld-i386/pr19031a.c: Likewise.
* ld/testsuite/ld-i386/pr19031b.S: Likewise.
* ld/testsuite/ld-i386/pr19031c.c: 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 ld/19011] Issues with ld on mingw-w64 and bad defaults

2015-10-01 Thread nickc at redhat dot com

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

Nick Clifton  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from Nick Clifton  ---
Sorry - I am not on IRC, but do feel free to email me direct.

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/19013] Section corrupted with elf64-x86-64 input -> elf32-i386 output

[Bug ld/19030] ld generates .so/x86 with bad phdr so the Android linker won't dlopen

[Bug ld/19030] ld generates .so/x86 with bad phdr so the Android linker won't dlopen

[Bug ld/19030] ld generates .so/x86 with bad phdr so the Android linker won't dlopen

[Bug binutils/1198] Segfault when executing objdump on a special file...

[Bug ld/4897] [regression] failing testcases on m68k-linux-gnu

[Bug binutils/1298] m68k-dis.c:1348: warning: argument 'info' might be clobbered by 'longjmp' or 'vfork'

[Bug gas/11030] Missing opcode for assembly instruction 'stldsr' in isa aplus of m68k assembler

[Bug gold/19042] New: unsupported reloc 311/312

[Bug binutils/18995] c++filt segfault on line not containing a symbol

[Bug gold/19044] New: Gold links single-threaded program into a deadlock on i686 Linux

[Bug ld/19030] ld generates .so/x86 with bad phdr so the Android linker won't dlopen

[Bug gold/19041] New: unsupported TLSLE reloc 549/551

[Bug gas/14193] mov3q.l followed by movem.l generates illegal instruction on Coldfire 5480 (or -march=cfv4e)

[Bug gold/19047] gold --icf vs REL with negative addend

[Bug gold/19031] R_386_PC32 does not imply a call

[Bug gold/19047] New: gold --icf vs REL with negative addend

[Bug gold/19031] R_386_PC32 does not imply a call

[Bug gold/19042] unsupported reloc 311/312

[Bug gold/19041] unsupported TLSLE reloc 549/551

Can gold's max page size for AArch64 be updated to 64k to match current kernel capabilities?

[Bug gold/19031] R_386_PC32 does not imply a call

[Bug gold/19031] R_386_PC32 does not imply a call

[Bug ld/19013] Section corrupted with elf64-x86-64 input -> elf32-i386 output

[Bug gold/19031] New: R_386_PC32 does not imply a call

[Bug gold/19031] R_386_PC32 does not imply a call

[Bug ld/19011] Issues with ld on mingw-w64 and bad defaults

27 matches

Site Navigation

Mail list logo

Footer information