[Bug ld/19368] [2.26/2.27 regression] IFUNC support not working on arm-linux-gnueabi*
https://sourceware.org/bugzilla/show_bug.cgi?id=19368 --- Comment #9 from cvs-commit at gcc dot gnu.org --- The binutils-2_26-branch branch has been updated by Jiong Wang : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e48a6a3c4a4ae7a343dd54348d37bf9e0f246735 commit e48a6a3c4a4ae7a343dd54348d37bf9e0f246735 Author: Jiong Wang Date: Mon Jan 11 10:49:57 2016 + [BACKPORT][ARM] PR ld/19368: Add missing relocation type class for R_ARM_IRELATIVE Apply from master 2016-01-08 Richard Sandiford Jiong Wang bfd/ PR ld/19368 * elf32-arm.c (elf32_arm_reloc_type_class): Map R_ARM_IRELATIVE to reloc_class_ifunc. ld/testsuite/ * testsuite/ld-arm/ifunc-3.rd: Update expected result. * testsuite/ld-arm/ifunc-4.rd: Likewise. * testsuite/ld-arm/ifunc-9.rd: Likewise. * testsuite/ld-arm/ifunc-10.rd: Likewise. * testsuite/ld-arm/ifunc-12.rd: Likewise. * testsuite/ld-arm/ifunc-13.rd: 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/18199] ld fails with -flto for mingw, wrong resolution for main
https://sourceware.org/bugzilla/show_bug.cgi?id=18199 --- Comment #6 from cvs-commit at gcc dot gnu.org --- The binutils-2_26-branch branch has been updated by Kwok Yeung : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=412d26bde8585eca3ec6b8bed70197205288cbdf commit 412d26bde8585eca3ec6b8bed70197205288cbdf Author: Kwok Cheung Yeung Date: Thu Dec 10 16:11:07 2015 + ld: Fix LTO for MinGW targets When creating a dummy BFD for an IR file, the output BFD is used as a template for the new BFD, when it needs to be the input BFD passed into the function when not dealing with a BFD plugin. On most targets this is not an issue as the input and output formats are the same anyway, but on MinGW targets, there are two variant formats used (pe-i386/pe-x86-64 and pei-i386/pei-x86-64) which are similar but not interchangeable here. PR ld/18199 * plugin.c (plugin_get_ir_dummy_bfd): Use srctemplate as the template when calling bfd_create if it does not use the BFD plugin target vector. (Cherry-picked from commit 4a07dc81356ed8728e204e9aabeb256703c59aef) -- 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
https://sourceware.org/bugzilla/show_bug.cgi?id=19011 Domani Hannes changed: What|Removed |Added CC||ssbssa at yahoo dot de -- 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/12658] ld: potential infinite loop and memory leaks when link many object files
https://sourceware.org/bugzilla/show_bug.cgi?id=12658 Domani Hannes changed: What|Removed |Added CC||ssbssa at yahoo dot de -- 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/19446] New: BFD linker discards section without alloc section attribute under certain conditions
https://sourceware.org/bugzilla/show_bug.cgi?id=19446 Bug ID: 19446 Summary: BFD linker discards section without alloc section attribute under certain conditions Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: xinliangli at gmail dot com Target Milestone: --- If a section is not marked with SHF_ALLOC attribute and when --gc-sections is on, the BFD linker only keeps it if the section has no references to other symbols. If there is reference to other symbols, the linker will garbage collect it. By comparison, Gold linker does not garbage collect such sections regardless of the contents of the section. Example: t.s gcc -fuse-ld=bfd -Wl,--gc-sections t.s objdump -h a.out |grep UNREF Changing the assembly file a little by making unref initialized to 0, linker will keep the UNREF section. The version of the linker tested is 2.24. .file "unref2.c" .comm g0,4,4 .globl unref .sectionUNREF,"",@progbits .align 8 .type unref, @object .size unref, 8 unref: .quad g0 .text .globl main .type main, @function main: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq%rsp, %rbp .cfi_def_cfa_register 6 movl$1, %eax popq%rbp .cfi_def_cfa 7, 8 ret .cfi_endproc .LFE0: .size main, .-main .ident "GCC: (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4" .section.note.GNU-stack,"",@progbits -- 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/19446] BFD linker discards section without alloc section attribute under certain conditions
https://sourceware.org/bugzilla/show_bug.cgi?id=19446 David Li changed: What|Removed |Added CC||ccoutant at gmail dot com, ||hjl.tools 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/19446] BFD linker discards section without alloc section attribute under certain conditions
https://sourceware.org/bugzilla/show_bug.cgi?id=19446 H.J. Lu changed: What|Removed |Added Status|NEW |WAITING --- Comment #1 from H.J. Lu --- Since UNREF section is not referenced, it should be GCed. Am I missing something? -- 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/19446] BFD linker discards section without alloc section attribute under certain conditions
https://sourceware.org/bugzilla/show_bug.cgi?id=19446 --- Comment #2 from David Li --- (In reply to H.J. Lu from comment #1) > Since UNREF section is not referenced, it should be GCed. Am I missing > something? Note that the section does not have 'a' bit -- just like debug sections. Linker won't GC debug sections, right? Also there is inconsistent behavior here -- when g0 is not referenced by UNREF, UNREF will be kept by the linker. -- 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/19446] BFD linker discards section without alloc section attribute under certain conditions
https://sourceware.org/bugzilla/show_bug.cgi?id=19446 --- Comment #3 from H.J. Lu --- (In reply to David Li from comment #2) > (In reply to H.J. Lu from comment #1) > > Since UNREF section is not referenced, it should be GCed. Am I missing > > something? > > Note that the section does not have 'a' bit -- just like debug sections. > Linker won't GC debug sections, right? ld only treats known debug sections as debug sections. Are you looking for a way to prevent unreferenced section from GC? > Also there is inconsistent behavior here -- when g0 is not referenced by > UNREF, UNREF will be kept by the linker. g0 is removed by ld in binutils 2.26. -- 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/19446] BFD linker discards section without alloc section attribute under certain conditions
https://sourceware.org/bugzilla/show_bug.cgi?id=19446 --- Comment #4 from David Li --- (In reply to H.J. Lu from comment #3) > (In reply to David Li from comment #2) > > (In reply to H.J. Lu from comment #1) > > > Since UNREF section is not referenced, it should be GCed. Am I missing > > > something? > > > > Note that the section does not have 'a' bit -- just like debug sections. > > Linker won't GC debug sections, right? > > ld only treats known debug sections as debug sections. Are you looking > for a way to prevent unreferenced section from GC? yes. > > > Also there is inconsistent behavior here -- when g0 is not referenced by > > UNREF, UNREF will be kept by the linker. > > g0 is removed by ld in binutils 2.26. No -- that is not the point. The point is that if UNDEF section is defined as follows, ld *will* keep UNREF (I have not tried 2.26). What makes ld think UNREF should be kept here as they are not known debug sections? .globl unref .sectionUNREF,"",@progbits .align 8 .type unref, @object .size unref, 8 unref: .long 0 .text .globl main .type main, @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 binutils/19446] BFD linker discards section without alloc section attribute under certain conditions
https://sourceware.org/bugzilla/show_bug.cgi?id=19446 --- Comment #5 from H.J. Lu --- (In reply to David Li from comment #4) > (In reply to H.J. Lu from comment #3) > > (In reply to David Li from comment #2) > > > (In reply to H.J. Lu from comment #1) > > > > Since UNREF section is not referenced, it should be GCed. Am I missing > > > > something? > > > > > > Note that the section does not have 'a' bit -- just like debug sections. > > > Linker won't GC debug sections, right? > > > > ld only treats known debug sections as debug sections. Are you looking > > for a way to prevent unreferenced section from GC? > > yes. > Will .globl unref .sectionUNREF,"",@note .align 8 .type unref, @object .size unref, 8 unref: .quad g0 work for you? > > > > > Also there is inconsistent behavior here -- when g0 is not referenced by > > > UNREF, UNREF will be kept by the linker. > > > > g0 is removed by ld in binutils 2.26. > > No -- that is not the point. The point is that if UNDEF section is defined > as follows, ld *will* keep UNREF (I have not tried 2.26). What makes ld > think UNREF should be kept here as they are not known debug sections? > > > > .globl unref > .sectionUNREF,"",@progbits > .align 8 > .type unref, @object > .size unref, 8 > unref: > .long 0 > > .text > .globl main > .type main, @function GCC in ld in binutils 2.26 will remove 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 binutils/19421] [2.26 Regression] Missing weak symbols in kernel modules on powerpc64le-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=19421
Alan Modra changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at sourceware dot org |amodra at gmail dot com
--- Comment #3 from Alan Modra ---
So far, I haven't been able to reproduce this problem using torvalds linux git
kernel and current binutils.
There are lots of claims in the debian bug report:
1)
fat: no symbol version for TOC.
fat: Unknown symbol TOC. (err -22)
ext4: no symbol version for TOC.
ext4: Unknown symbol TOC. (err -22)
and others like this.
This can happen if there is no entry for "TOC." in the __versions section of a
module, but I see for example
objdump -sj__versions fs/binfmt_misc.ko
...
0e00 2e544f43 2e00 .TOC
0e10
0e20
0e30
...
I picked on binfmt_misc.ko rather than the fat or ext4 modules since
binfmt_misc.ko is built for "make defconfig", but I see the same with ext4.ko
after flipping the appropriate .config lines.
2)
Changed section ordering for -z relro. This shouldn't be a problem, but may be
one of the triggers for (4) below.
3)
Normally a ppc64el kernel has the following undefined symbols:
| 44809: 0 NOTYPE WEAK DEFAULT UND mach_powermac
| 52870: 0 NOTYPE WEAK DEFAULT UND mach_chrp
| 62021: 0 NOTYPE WEAK DEFAULT UND mach_cell
| 62383: 0 NOTYPE WEAK DEFAULT UND __crc_TOC.
Also not a problem if these symbols disappear when undefined, I think. The
mach_* symbols are used in the following macro
#define machine_is(name) \
({ \
extern struct machdep_calls mach_##name \
__attribute__((weak)); \
machine_id == &mach_##name; \
})
A missing kernel symbol will be silently resolved to 0 if the reference is
STB_WEAK as far as I can see from my reading kernel/module.c. This of course
is the same value if the symbol is found. __crc_TOC. is similar (but I'm still
investigating this one).
4)
the mcount symbol error
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68759
If you're building with gcc-6, you will need a kernel 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/19353] ld-new: internal error in relocate_tls, at ../../binutils/gold/aarch64.cc:7418
https://sourceware.org/bugzilla/show_bug.cgi?id=19353
Cary Coutant changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|ccoutant at gmail dot com |shenhan at google dot
com
--- Comment #5 from Cary Coutant ---
(In reply to Han Shen from comment #4)
> Hi, Kristof, I was able to reproduce case 2 (but not 1).
>
> In gold, tls_segment is never created in layout.cc, so comes the assertion.
> In call_once.o, there is the tls symbol _ZSt15__once_callable, however there
> is no sections that has bit elfcpp::SHF_TLS turned on, and tls_segment is
> only created if there is at least one sectoin with SHF_TLS bit.
>
> So, Cary, shall we create the tls_segment whenever the Scanner encounters a
> tls symbol?
It looks like this is in relocate_tls(), in this block:
case elfcpp::R_AARCH64_TLSDESC_ADR_PAGE21:
case elfcpp::R_AARCH64_TLSDESC_LD64_LO12:
case elfcpp::R_AARCH64_TLSDESC_ADD_LO12:
case elfcpp::R_AARCH64_TLSDESC_CALL:
...
if (tlsopt == tls::TLSOPT_TO_IE)
{
if (tls_segment == NULL)
{
gold_assert(parameters->errors()->error_count() > 0
|| issue_undefined_symbol_error(gsym));
return aarch64_reloc_funcs::STATUS_BAD_RELOC;
}
return tls_desc_gd_to_ie(relinfo, target, rela, r_type,
view, psymval, got_entry_address,
address);
}
at the gold_assert() there. Is that where the assert is happening for you?
Looking at tls_desc_gd_to_ie(), and comparing this with the similar case in the
x86 backend, it looks to me like the insistence on having a non-NULL
tls_segment here is too zealous -- the optimization from GD to IE never needs
tls_segment, and it's perfectly reasonable to have a relocation to an external
TLS symbol without having a TLS segment in the main executable.
I think if you simply remove the "if (tls_segment == NULL) { ... }" block here,
it will fix the problem.
--
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/19446] BFD linker discards section without alloc section attribute under certain conditions
https://sourceware.org/bugzilla/show_bug.cgi?id=19446 --- Comment #6 from David Li --- (In reply to H.J. Lu from comment #5) > (In reply to David Li from comment #4) > > (In reply to H.J. Lu from comment #3) > > > (In reply to David Li from comment #2) > > > > (In reply to H.J. Lu from comment #1) > > > > > Since UNREF section is not referenced, it should be GCed. Am I > > > > > missing > > > > > something? > > > > > > > > Note that the section does not have 'a' bit -- just like debug sections. > > > > Linker won't GC debug sections, right? > > > > > > ld only treats known debug sections as debug sections. Are you looking > > > for a way to prevent unreferenced section from GC? > > > > yes. > > > > Will > > .globl unref > .sectionUNREF,"",@note > .align 8 > .type unref, @object > .size unref, 8 > unref: > .quad g0 > > work for you? > > > > > > > > Also there is inconsistent behavior here -- when g0 is not referenced by > > > > UNREF, UNREF will be kept by the linker. > > > > > > g0 is removed by ld in binutils 2.26. > > > > No -- that is not the point. The point is that if UNDEF section is defined > > as follows, ld *will* keep UNREF (I have not tried 2.26). What makes ld > > think UNREF should be kept here as they are not known debug sections? > > > > > > > > .globl unref > > .sectionUNREF,"",@progbits > > .align 8 > > .type unref, @object > > .size unref, 8 > > unref: > > .long 0 > > > > .text > > .globl main > > .type main, @function > > GCC in ld in binutils 2.26 will remove it. making it a note section works fine for both ld and 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 gold/19353] ld-new: internal error in relocate_tls, at ../../binutils/gold/aarch64.cc:7418
https://sourceware.org/bugzilla/show_bug.cgi?id=19353 Cary Coutant changed: What|Removed |Added CC||ccoutant at gmail dot com Assignee|shenhan at google dot com |ccoutant at gmail dot com --- Comment #6 from Cary Coutant --- In fact, if I compile the example for x86-64 with -mtls-dialect=gnu2, I see the same failure. In x86_64.cc, we don't check for tls_segment when optimizing R_X86_64_TLSGD to IE, but we do have a bogus check when optimizing R_X86_64_GOTPC32_TLSDESC or R_X86_64_TLSDESC_CALL. We have a similar problem in i386.cc. It looks like the aarch64.cc target simply inherited the bug from x86_64.cc. -- 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/19353] ld-new: internal error in relocate_tls, at ../../binutils/gold/aarch64.cc:7418
https://sourceware.org/bugzilla/show_bug.cgi?id=19353 --- Comment #7 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=d21f123b0ead1806416cf0dafae12bec4cca8920 commit d21f123b0ead1806416cf0dafae12bec4cca8920 Author: Cary Coutant Date: Mon Jan 11 23:57:44 2016 -0800 Fix internal error when applying TLSDESC relocations with no TLS segment. gold/ PR gold/19353 * aarch64.cc (Target_aarch64::relocate_tls): Don't insist that we have a TLS segment for GD-to-IE optimization. * i386.cc (Target_i386::tls_gd_to_ie): Remove tls_segment parameter. Adjust all calls. (Target_i386::tls_desc_gd_to_ie): Likewise. (Target_i386::relocate_tls): Don't insist that we have a TLS segment for TLSDESC GD-to-IE optimizations. * x86_64.cc (Target_x86_64::tls_gd_to_ie): Remove tls_segment parameter. Adjust all calls. (Target_x86_64::tls_desc_gd_to_ie): Likewise. (Target_x86_64::relocate_tls): Don't insist that we have a TLS segment for TLSDESC GD-to-IE optimizations. -- 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
