[Bug binutils/22465] objcopy interleave fails if section address not multiple of interleave
https://sourceware.org/bugzilla/show_bug.cgi?id=22465 --- Comment #4 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=7d6de425dad59050131ac4ffef84068e57bba7c4 commit 7d6de425dad59050131ac4ffef84068e57bba7c4 Author: Alan Modra Date: Thu Dec 7 21:46:34 2017 +1030 Objcopy interleave test PR 22465 * testsuite/ld-elf/interleave.s: Use .data sections and provide section attrs. * testsuite/ld-elf/interleave.ld: Discard other sections. Adjust for changed section names. -- 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/22566] New: --gc-sections preserves hidden symbols if initial definition has default visibility
https://sourceware.org/bugzilla/show_bug.cgi?id=22566 Bug ID: 22566 Summary: --gc-sections preserves hidden symbols if initial definition has default visibility Product: binutils Version: 2.30 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: amonakov at gmail dot com CC: ian at airs dot com Target Milestone: --- ELF spec states that the most constraining visibility is taken from all definitions and references to the symbol to find the final visibility status. In the following example, Gold correctly computes the final visibility (hidden, taken from t2.o), but if t1.o comes first on the command line, Gold marks foo as a GC root too early. The BFD linker gets this right in both cases. t1.s: .globl foo foo: .zero 4096 t2.s: .hidden foo .int foo-. $ ld.gold -shared -gc-sections t2.o t1.o && size -A a.out | grep text [no output, -gc-sections works as expected] $ ld.gold -shared -gc-sections t1.o t2.o && size -A a.out | grep text .text4096464 $ readelf -a a.out |grep foo 1: 01d0 0 NOTYPE LOCAL HIDDEN 4 foo -- 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/22547] Incorrect demangling of lambda destructors?
https://sourceware.org/bugzilla/show_bug.cgi?id=22547
Tom Tromey changed:
What|Removed |Added
CC||tromey at sourceware dot org
--- Comment #1 from Tom Tromey ---
On irc, Nathan agreed with this analysis and came up with this test case:
struct X { ~X (); };
void foo (X x) { [=] () { x; } (); }
_ZZ3foo1XENUlvE_D1Ev
--
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/22570] ld fails to bind DTPMOD at link time for pie on mips
https://sourceware.org/bugzilla/show_bug.cgi?id=22570 Rich Felker changed: What|Removed |Added Target||mips*-*-*-* -- 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/22570] New: ld fails to bind DTPMOD at link time for pie on mips
https://sourceware.org/bugzilla/show_bug.cgi?id=22570
Bug ID: 22570
Summary: ld fails to bind DTPMOD at link time for pie on mips
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
When a symbol is defined and referenced in the main program, DTPMOD relocations
should be bound at ld time to module 1. This is mandatory for static linking
and merely an optimization in the case of dynamic linking. However the logic in
elfxx-mips.c's mips_elf_initialize_tls_slots() function is not pie-aware, and
uses info->shared rather than !info->executable as the condition for "output is
a shared library", thereby disabling the logic to resolve DTPMOD at link time.
As a result, static pie executables contain a DTPMOD relocation and will not
work without spurious runtime code to resolve it.
Note that this would be a non-issue if mips targets had TLS relaxation, but as
far as I can tell they don't. I suspect the same issue may exist on other
targets that lack relaxations but I was not able to find the corresponding
code.
Simple test case:
__thread int x = 42;
int main() { return x; }
The output, compiled with -fPIC (rather than -fPIE, to ensure that GD model
access is generated) and linked with -pie, should not contain any
R_MIPS_TLS_DTPMOD relocations, but does.
--
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/21545] relro_test.sh can be simplified, eliminating dependency on dc
https://sourceware.org/bugzilla/show_bug.cgi?id=21545 Jonathan Cottrill changed: What|Removed |Added CC||sourceware@jonathancottrill ||.net -- 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/22571] New: libbfd: bfd_get_symtab_upper_bound causes SIGSEGV when iterating archive files
https://sourceware.org/bugzilla/show_bug.cgi?id=22571
Bug ID: 22571
Summary: libbfd: bfd_get_symtab_upper_bound causes SIGSEGV when
iterating archive files
Product: binutils
Version: 2.29
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: sourceware at jonathancottrill dot net
Target Milestone: ---
Created attachment 10670
--> https://sourceware.org/bugzilla/attachment.cgi?id=10670&action=edit
Simple C program demonstrating SIGSEGV issue
In a symbol processing program I'm writing, I'm iterating through an archive,
using bfd_openr_next_archived_file followed by bfd_get_symtab_upper_bound. The
first iteration is successful, but the second file causes a SIGSEGV in the
bfd_get_symtab_upper_bound call. This seems to happen with any archive (I've
tried several Linux ELF .a archives, and one Windows COFF .lib archive).
A simplified case that demonstrates the problem is:
bfd* file = NULL;
while ((file = bfd_openr_next_archived_file(archive, file)) != NULL) {
printf("File: %s\n", file->filename);
long storage_needed = bfd_get_symtab_upper_bound(file);
printf(" symbol table: %li bytes\n", storage_needed);
}
Example output is:
File: file-a.o
symbol table: 72 bytes
File: file-b.o
Segmentation fault (core dumped)
GDB shows:
Program received signal SIGSEGV, Segmentation fault.
0x779574c2 in _bfd_elf_get_symtab_upper_bound (abfd=0x607b20) at
../../bfd/elf.c:8023
8023 symcount = hdr->sh_size / get_elf_backend_data (abfd)->s->sizeof_sym;
If it matters, this is on openSUSE 42.3 x86_64, using either the system
libbfd-2.29.1.so library or building the library myself from your Git repo.
I've attached the file uselibbfd.c, a complete and simple program demonstrating
the issue. Also, I'll attach the coredump.
Please let me know what other information you need.
Thanks!
Notes:
I'm relying on documentation here for the libbfd calls I'm making:
https://sourceware.org/binutils/docs-2.29/bfd/Archives.html
https://sourceware.org/binutils/docs-2.29/bfd/Reading-Symbols.html
--
I can reproduce the problem with an archive built using:
ar rcs archive.a file-a.o file-b.o
...where file-a.o and file-b.o are compiled using gcc -c file-*.c, and the C
source files are simply:
file-a.c:
void functionA() {
}
file-b.c:
void functionB() {
}
--
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/22571] libbfd: bfd_get_symtab_upper_bound causes SIGSEGV when iterating archive files
https://sourceware.org/bugzilla/show_bug.cgi?id=22571 Jonathan Cottrill changed: What|Removed |Added CC||sourceware@jonathancottrill ||.net --- Comment #1 from Jonathan Cottrill --- Created attachment 10671 --> https://sourceware.org/bugzilla/attachment.cgi?id=10671&action=edit Coredump -- 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
