[Bug gold/22233] [2.29 Regression] gold segfault in relocate_erratum_stub on aarch64-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=22233 --- Comment #4 from Peter Smith --- Thanks for the comment, I'll leave the patch as it is for now as I think it helps to have the view_offset added in each case. Happy to remove it if others prefer though. -- 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/22431] ld (binutils-2.29) segfaults when building Linux kernel (v4.14) on Fedora 26 ppc64le
https://sourceware.org/bugzilla/show_bug.cgi?id=22431 --- Comment #2 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=06bcf5416feae129e239476ab1408e038bba171d commit 06bcf5416feae129e239476ab1408e038bba171d Author: Alan Modra Date: Tue Nov 14 18:47:34 2017 +1030 PR22431, powerpc64 ld segfault when .plt discarded The fix for the PR is to not use input_section->output_section->owner to get to the output bfd, but use the output bfd directly since it is available nowadays in struct bfd_link_info. I thought it worth warning when non-empty dynamic sections are discarded too, which meant a tweak to one of the ld tests to avoid the warning. bfd/ PR 22431 * elf64-ppc.c (ppc64_elf_size_dynamic_sections): Warn on discarding non-empty dynamic section. (ppc_build_one_stub): Take elf_gp from output bfd, not output section owner. (ppc_size_one_stub, ppc64_elf_next_toc_section): Likewise. ld/ * testsuite/ld-elf/note-3.t: Don't discard .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/22431] powerpc64 ld segfault when .plt discarded
https://sourceware.org/bugzilla/show_bug.cgi?id=22431 Alan Modra changed: What|Removed |Added CC|amodra at gmail dot com| Summary|ld (binutils-2.29) |powerpc64 ld segfault when |segfaults when building |.plt discarded |Linux kernel (v4.14) on | |Fedora 26 ppc64le | --- Comment #3 from Alan Modra --- Fixed on master. The results are now: ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'. ld: warning: discarding dynamic section .glink ld: warning: discarding dynamic section .plt ld: linkage table error against `cfhsi_get_ops' ld: stubs don't match calculated size ld: can not build stubs: Bad value I'll likely backport this to 2.29 in a few days if I don't get complaints about the new warning. -- 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/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 --- Comment #20 from H.J. Lu --- (In reply to Jan Beulich from comment #19) > (In reply to H.J. Lu from comment #18) > > (In reply to Jan Beulich from comment #17) > > > This is a tentative patch which could replace the bad one. Only tested on > > > 2.29.1 so far. > > > > Does GCC behave the same with and without -asm=intel with your change? > > As long as there's only a single segment override - of course. Obviously > multiple (redundant) segment overrides would then be accepted again, as they > should be. But as long as gcc cares, it should emit anything like that. No, they should not by gas. MASM is totally irrelevant here. -- 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/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 --- Comment #21 from Jan Beulich --- (In reply to H.J. Lu from comment #20) > MASM is totally irrelevant here. This is your opinion, which I don't share. Is this formally written down anywhere? Plus the presence of a MASM syntax expression parser pretty clearly contradicts this statement of yours. -- 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/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 --- Comment #22 from H.J. Lu --- (In reply to Jan Beulich from comment #21) > (In reply to H.J. Lu from comment #20) > > MASM is totally irrelevant here. > > This is your opinion, which I don't share. Is this formally written down > anywhere? Plus the presence of a MASM syntax expression parser pretty > clearly contradicts this statement of yours. As I said, the main purpose of gas is to serve GCC. The MASM syntax expression parser supports -masm=intel. But we don't pursue MASM compatibility by making gas itself inconsistent. At very minimum, a warning should be issued by default, which can be controlled by -moperand-check=[none|error|warning] -- 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/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 --- Comment #23 from Jan Beulich --- (In reply to H.J. Lu from comment #22) > The MASM syntax expression parser supports -masm=intel. How that? The compiler doesn't emit expressions, it does all the calculations and emits plain numbers. Are you perhaps mixing up expressions and things like "dword ptr" specifiers (which aren't themselves expressions)? > At very minimum, a warning should be issued by default, which can be > controlled > by > > -moperand-check=[none|error|warning] I can certainly arrange for that, albeit it's a waste of time (and may defer when I get to submit the replacement patch, while I'll surely revert the original one before the next release bets branched, unless you finally show willingness to fix the regression you've introduced). -- 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/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 --- Comment #24 from H.J. Lu --- (In reply to Jan Beulich from comment #23) > (In reply to H.J. Lu from comment #22) > > The MASM syntax expression parser supports -masm=intel. > > How that? The compiler doesn't emit expressions, it does all the > calculations and emits plain numbers. Are you perhaps mixing up expressions > and things like "dword ptr" specifiers (which aren't themselves expressions)? > > > At very minimum, a warning should be issued by default, which can be > > controlled > > by > > > > -moperand-check=[none|error|warning] > > I can certainly arrange for that, albeit it's a waste of time (and may defer > when I get to submit the replacement patch, while I'll surely revert the > original one before the next release bets branched, unless you finally show Please don't do 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 gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 --- Comment #25 from Jan Beulich --- (In reply to H.J. Lu from comment #24) > Please don't do that. Why would I not? As indicated, you didn't obtain maintainer approval. In fact I've just checked the mailing list archives - you didn't even think you would need to, as you've sent the mail (according to its subject) only after the commit. The amount of trouble you give me elsewhere (largely defeating my intention of improving the overall code, using time I could equally well spend on other things), I don't see any reason at all why I shouldn't insist on proper process here. -- 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/22266] ld.gold produces invalid output when linking with --relocatable
https://sourceware.org/bugzilla/show_bug.cgi?id=22266 H.J. Lu changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2017-11-14 Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #5 from H.J. Lu --- It fails with GCC 4.2 on i686: FAIL: pr22266 (exit: 134) -- 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/22266] ld.gold produces invalid output when linking with --relocatable
https://sourceware.org/bugzilla/show_bug.cgi?id=22266
--- Comment #6 from H.J. Lu ---
(gdb) r
Starting program:
/export/build/gnu/binutils-gold/build-i686-linux/gold/testsuite/pr22266
Program received signal SIGABRT, Aborted.
0x00164410 in __kernel_vsyscall ()
(gdb) bt
#0 0x00164410 in __kernel_vsyscall ()
#1 0x00b8adf0 in raise () from /lib/libc.so.6
#2 0x00b8c701 in abort () from /lib/libc.so.6
#3 0x0804841e in main ()
at
/export/gnu/import/git/sources/binutils-gdb/gold/testsuite/pr22266_main.c:7
(gdb) f 3
#3 0x0804841e in main ()
at
/export/gnu/import/git/sources/binutils-gdb/gold/testsuite/pr22266_main.c:7
7 abort ();
(gdb) list
2
3 extern int *p_int_from_a_2;
4
5 int main (void) {
6 if (*p_int_from_a_2 != 0x11223344)
7 abort ();
8 return 0;
9 }
(gdb) p *p_int_from_a_2
$1 = 0
(gdb)
--
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/22266] ld.gold produces invalid output when linking with --relocatable
https://sourceware.org/bugzilla/show_bug.cgi?id=22266 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #7 from H.J. Lu --- Created attachment 10589 --> https://sourceware.org/bugzilla/attachment.cgi?id=10589&action=edit A testcase [hjl@gnu-6 tmp]$ ld.bfd -m elf_i386 -r -T /export/gnu/import/git/sources/binutils-gdb/gold/testsuite/pr22266_script.t -o pr22266_ar.o pr22266_a.o [hjl@gnu-6 tmp]$ gcc -m32 pr22266_main.o pr22266_ar.o [hjl@gnu-6 tmp]$ ./a.out [hjl@gnu-6 tmp]$ /export/build/linux/binutils-x32/build-x86_64-linux-gnux32/gold/ld-new -m elf_i386 -r -T /export/gnu/import/git/sources/binutils-gdb/gold/testsuite/pr22266_script.t -o pr22266_ar.o pr22266_a.o [hjl@gnu-6 tmp]$ gcc -m32 pr22266_main.o pr22266_ar.o [hjl@gnu-6 tmp]$ ./a.out Aborted [hjl@gnu-6 tmp]$ -- 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/22266] ld.gold produces invalid output when linking with --relocatable
https://sourceware.org/bugzilla/show_bug.cgi?id=22266 --- Comment #8 from H.J. Lu --- (In reply to H.J. Lu from comment #7) > Created attachment 10589 [details] > A testcase > > [hjl@gnu-6 tmp]$ ld.bfd -m elf_i386 -r -T > /export/gnu/import/git/sources/binutils-gdb/gold/testsuite/pr22266_script.t > -o pr22266_ar.o pr22266_a.o > [hjl@gnu-6 tmp]$ gcc -m32 pr22266_main.o pr22266_ar.o > [hjl@gnu-6 tmp]$ ./a.out > [hjl@gnu-6 tmp]$ > /export/build/linux/binutils-x32/build-x86_64-linux-gnux32/gold/ld-new -m > elf_i386 -r -T > /export/gnu/import/git/sources/binutils-gdb/gold/testsuite/pr22266_script.t > -o pr22266_ar.o pr22266_a.o > [hjl@gnu-6 tmp]$ gcc -m32 pr22266_main.o pr22266_ar.o > [hjl@gnu-6 tmp]$ ./a.out > Aborted > [hjl@gnu-6 tmp]$ Revert Fix problems with -r. The fix committed for PR gold/19291 ended up breaking other cases. The commit added adjustment code to write_local_symbols, but in many cases compute_final_local_value_internal had already subtracted the output section's address. To fix this, all other adjustments are now removed, so only the one in write_local_symbols is left. gold/ PR gold/22266 * object.cc (Sized_relobj_file::compute_final_local_value_internal): Drop relocatable parameter and stop adjusting output value based on it. (Sized_relobj_file::compute_final_local_value): Stop passing relocatable to compute_final_local_value_internal. (Sized_relobj_file::do_finalize_local_symbols): Ditto. * object.h (Sized_relobj_file::compute_final_local_value_internal): Drop relocatable parameter. fixed this 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/22266] ld.gold produces invalid output when linking with --relocatable
https://sourceware.org/bugzilla/show_bug.cgi?id=22266 --- Comment #9 from H.J. Lu --- Symbol table is wrong: --- 2 2017-11-14 08:54:05.933477729 -0800 +++ 1 2017-11-14 08:54:23.381514511 -0800 @@ -84,7 +84,7 @@ Symbol table '.symtab' contains 10 entri 5: 0 SECTION LOCAL DEFAULT7 6: 0 SECTION LOCAL DEFAULT9 7: 0 FILELOCAL DEFAULT ABS pr22266_a.c - 8: fffc 4 OBJECT LOCAL DEFAULT2 int_from_a_1 ^^ Good + 8: 4 OBJECT LOCAL DEFAULT2 int_from_a_1 ^^^ Bad 9: 4 OBJECT GLOBAL DEFAULT4 p_int_from_a_2 -- 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/22266] ld.gold produces invalid output when linking with --relocatable
https://sourceware.org/bugzilla/show_bug.cgi?id=22266 --- Comment #10 from H.J. Lu --- The content of .data.rel.ro section is also wrong. -- 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/22266] ld.gold produces invalid output when linking with --relocatable
https://sourceware.org/bugzilla/show_bug.cgi?id=22266 H.J. Lu changed: What|Removed |Added Status|REOPENED|NEW --- Comment #11 from H.J. Lu --- This isn't GCC version related. It failed on all REL targets. RELA targets are OK. -- 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/22266] ld.gold produces invalid output when linking with --relocatable
https://sourceware.org/bugzilla/show_bug.cgi?id=22266 H.J. Lu changed: What|Removed |Added Version|2.28|2.30 (HEAD) -- 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/22266] ld.gold produces invalid output when linking with --relocatable
https://sourceware.org/bugzilla/show_bug.cgi?id=22266 --- Comment #12 from James Clarke --- (In reply to H.J. Lu from comment #9) > Symbol table is wrong: > > --- 2 2017-11-14 08:54:05.933477729 -0800 > +++ 1 2017-11-14 08:54:23.381514511 -0800 > @@ -84,7 +84,7 @@ Symbol table '.symtab' contains 10 entri > 5: 0 SECTION LOCAL DEFAULT7 > 6: 0 SECTION LOCAL DEFAULT9 > 7: 0 FILELOCAL DEFAULT ABS pr22266_a.c > - 8: fffc 4 OBJECT LOCAL DEFAULT2 int_from_a_1 > ^^ Good > > + 8: 4 OBJECT LOCAL DEFAULT2 int_from_a_1 > ^^^ Bad > 9: 4 OBJECT GLOBAL DEFAULT4 p_int_from_a_2 It's not that the symbol table was wrong. Your so-called "good" version is wrong; the symbol is at offset 0 from its section .data, so it really should have value 0 in the object file like it does now. The problem is that, it seems, somewhere, the REL was accounting for this (which is probably why the symbol value issue was not noticed earlier), and now that the symbol value is fixed, the REL case is broken. You can see for yourself that the problem is that the object file contents at "p_int_from_a_2" is 0x4, but this addend should be 0. -- 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/22441] New: x86-64: wrong relocation type used for 32-bit index-with-no-base addressing
https://sourceware.org/bugzilla/show_bug.cgi?id=22441 Bug ID: 22441 Summary: x86-64: wrong relocation type used for 32-bit index-with-no-base addressing Product: binutils Version: 2.30 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: jbeulich at novell dot com Target Milestone: --- This piece of code .text .intel_syntax noprefix .global _start _start: ret apic_read: mov eax, [edi*4+APIC_BASE] ret apic_write: mov [edi*4+APIC_BASE], esi ret fails to link (with --defsym APIC_BASE=0xfee0 passed to ld). With the "*4" removed all works fine. Fix already submitted: https://sourceware.org/ml/binutils/2017-11/msg00234.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
