[Bug binutils/22348] New: Shared libraries on Mac OS fail when targeting crx and cr16
https://sourceware.org/bugzilla/show_bug.cgi?id=22348 Bug ID: 22348 Summary: Shared libraries on Mac OS fail when targeting crx and cr16 Product: binutils Version: 2.29 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: marc at groundctl dot com Target Milestone: --- Both opcodes/crx-dis.c and opcodex/cr16-dis.c define the symbols "instruction", "size_changed", and "processing_argument_number". Normally, this isn't a problem because those symbols are common and don't conflict when linking the shared library. However, on Mac OS libtool adds "-fno-common" to the compiler flags, which causes the symbols to be non-common and so they end up conflicting when the shared library is linked. This is most easily reproduced by configuring with "--disable-werror --enable-targets=crx,cr16 --enable-shared". "size_changed" and "processing_argument_number" can both be made static since they're never referenced outside their respective source files, but I'm not sure if "instruction" needs to be addressable from other source files. -- 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/23872] New: MinGW Binaries can be built with misaligned relocation information
https://sourceware.org/bugzilla/show_bug.cgi?id=23872 Bug ID: 23872 Summary: MinGW Binaries can be built with misaligned relocation information Product: binutils Version: 2.30 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: marc at groundctl dot com Target Milestone: --- Clang does not align certain sections in its object files, so when they are linked it is possible that the runtime relocation sections are not aligned. This causes the linker to re-align them, but the value of "rt_psrelocs_start" is set before the realignment, so when the dll is loaded it looks in the wrong place for the relocations and fails. This can be fixed by forcing realignment by adding the line ". = ALIGN(4);" to the linker script immediately before setting rt_psrelocs_start. This bug was also reported to MinGW64: https://sourceforge.net/p/mingw-w64/bugs/769/ -- 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/23486] GNU_PROPERTY_X86_ISA_1_USED isn't merged properly
https://sourceware.org/bugzilla/show_bug.cgi?id=23486 marc at groundctl dot com changed: What|Removed |Added CC||marc at groundctl 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/24191] New: Gold doesn't properly process relocations to deduplicated code
https://sourceware.org/bugzilla/show_bug.cgi?id=24191
Bug ID: 24191
Summary: Gold doesn't properly process relocations to
deduplicated code
Product: binutils
Version: 2.31
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: marc at groundctl dot com
CC: ian at airs dot com
Target Milestone: ---
$ cat x.cpp
class a {
virtual void c();
};
inline void a::c(){}
$ g++ -g -c x.cpp -o x.o
$ objdump --dwarf=decodedline -r -j.debug_line x.o
x.o: file format elf64-x86-64
Contents of the .debug_line section:
CU: x.cpp:
File nameLine numberStarting addressView
x.cpp 4 0
x.cpp 4 0x8
x.cpp 4 0xb
RELOCATION RECORDS FOR [.debug_line]:
OFFSET TYPE VALUE
002b R_X86_64_64 .text._ZN1a1cEv
$ ld.gold x.o x.o -o x.gold -lstdc++
$ objdump --dwarf=decodedline x.gold
x.gold: file format elf64-x86-64
Contents of the .debug_line section:
CU: x.cpp:
File nameLine numberStarting addressView
x.cpp 40x4002c0
x.cpp 40x4002c8
x.cpp 40x4002cb
CU: x.cpp:
File nameLine numberStarting addressView
x.cpp 4 0
x.cpp 4 0x8
x.cpp 4 0xb
$ ld.bfd x.o x.o -o x.bfd -lstdc++
ld.bfd: warning: cannot find entry symbol _start; defaulting to
00401000
$ objdump --dwarf=decodedline x.bfd
x.bfd: file format elf64-x86-64
Contents of the .debug_line section:
CU: x.cpp:
File nameLine numberStarting addressView
x.cpp 40x401000
x.cpp 40x401008
x.cpp 40x40100b
CU: x.cpp:
File nameLine numberStarting addressView
x.cpp 40x401000
x.cpp 40x401008
x.cpp 40x40100b
It appears that gold does not process the relocation in the second instance of
x.o, and so in the final binary there are 2 debug line entries; one pointing at
the correct address and one pointing at 0. This is handled correctly by
ld.bfd. This may be related to bug 16794.
--
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/24192] New: ld doesn't properly process relocations to deduplicated code in PE files
https://sourceware.org/bugzilla/show_bug.cgi?id=24192
Bug ID: 24192
Summary: ld doesn't properly process relocations to
deduplicated code in PE files
Product: binutils
Version: 2.32
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: marc at groundctl dot com
Target Milestone: ---
$ cat x.cpp
class a {
virtual void c();
};
inline void a::c(){}
$ i686-w64-mingw32-g++ -g -c x.cpp -fno-rtti -o x.o
$ objdump --dwarf=decodedline -r -j.debug_line x.o
x.o: file format pe-i386
Contents of the .debug_line section:
CU: x.cpp:
File nameLine numberStarting addressView
x.cpp 4 0
x.cpp 4 0x9
x.cpp 4 0xc
RELOCATION RECORDS FOR [.debug_line]:
OFFSET TYPE VALUE
002b dir32 .text$_ZN1a1cEv
$ i686-w64-mingw32-ld x.o x.o -o x.exe
$ objdump --dwarf=decodedline -r -j.debug_line x.exe
x.exe: file format pei-i386
Contents of the .debug_line section:
CU: x.cpp:
File nameLine numberStarting addressView
x.cpp 40x401000
x.cpp 40x401009
x.cpp 40x40100c
CU: x.cpp:
File nameLine numberStarting addressView
x.cpp 4 0
x.cpp 4 0x9
x.cpp 4 0xc
This has the same symptoms as bug 24191. Compiling with -fno-rtti is not
necessary to reproduce this, it just makes the link line simpler and the
objdump output shorter. This also happens when ld is run indirectly via g++.
--
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
