[Bug binutils/24321] Objcopy "--only-keep-debug" generates Bad Offset in LOAD sections for lld built binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=24321 --- Comment #4 from Manoj Gupta --- Thanks, Looks like the internal tooling had an incorrect assumption. Sorry for the noise. -- 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/24319] Compressed / uncompressed debug info confusion in BFD
https://sourceware.org/bugzilla/show_bug.cgi?id=24319 --- Comment #2 from Alan Modra --- pr24005, I meant. -- 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/24321] Objcopy "--only-keep-debug" generates Bad Offset in LOAD sections for lld built binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=24321 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Alan Modra --- Yes, the section headers exist, but file offset is *not* preserved. This is not something unique to llvm objects, and not new behaviour. It dates back to binutils-2.15, this first binutils supporting --only-keep-debug. -- 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/24267] ld discards a symbol with -flto and -static
https://sourceware.org/bugzilla/show_bug.cgi?id=24267
--- Comment #22 from H.J. Lu ---
Works for me with binutils 2.32:
[hjl@gnu-cfl-2 pr24267]$ cat x.ii
namespace std {
template struct char_traits;
template > class basic_ostream;
typedef basic_ostream b;
class ios_base {
public:
class Init {
public:
Init();
};
};
template class ctype {
virtual char do_widen(char c) const { return c; }
};
class d {
ctype e;
};
template class basic_ostream : d {};
template
basic_ostream &operator<<(basic_ostream &, const char *);
b cout;
ios_base::Init g;
} // namespace std
int main() { std::cout << "ok"; }
[hjl@gnu-cfl-2 pr24267]$ x86_64-w64-mingw32-g++ -B./ -v -Wl,-v -flto -O2
-static x.ii
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-w64-mingw32/8.3.0/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../configure --prefix=/usr --bindir=/usr/bin
--includedir=/usr/include --mandir=/usr/share/man --infodir=/usr/share/info
--datadir=/usr/share --build=x86_64-redhat-linux-gnu
--host=x86_64-redhat-linux-gnu --with-gnu-as --with-gnu-ld --verbose
--without-newlib --disable-multilib --disable-plugin --with-system-zlib
--disable-nls --without-included-gettext --disable-win32-registry
--enable-languages=c,c++,objc,obj-c++,fortran
--with-bugurl=http://bugzilla.redhat.com/bugzilla --with-cloog
--enable-threads=posix --enable-libgomp --target=x86_64-w64-mingw32
--with-sysroot=/usr/x86_64-w64-mingw32/sys-root
--with-gxx-include-dir=/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++
Thread model: posix
gcc version 8.3.0 20190222 (Fedora MinGW 8.3.0-1.fc29) (GCC)
COLLECT_GCC_OPTIONS='-B' './' '-v' '-flto' '-O2' '-static' '-mtune=generic'
'-march=x86-64'
/usr/libexec/gcc/x86_64-w64-mingw32/8.3.0/cc1plus -fpreprocessed x.ii -quiet
-dumpbase x.ii -mtune=generic -march=x86-64 -auxbase x -O2 -version -flto -o
/tmp/ccgxROxd.s
GNU C++14 (GCC) version 8.3.0 20190222 (Fedora MinGW 8.3.0-1.fc29)
(x86_64-w64-mingw32)
compiled by GNU C version 8.2.1 20181215 (Red Hat 8.2.1-6), GMP version
6.1.2, MPFR version 3.1.6-p2, MPC version 1.1.0, isl version isl-0.16.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 8.3.0 20190222 (Fedora MinGW 8.3.0-1.fc29)
(x86_64-w64-mingw32)
compiled by GNU C version 8.2.1 20181215 (Red Hat 8.2.1-6), GMP version
6.1.2, MPFR version 3.1.6-p2, MPC version 1.1.0, isl version isl-0.16.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 782ecece326e64c4c9691227b10ab17e
COLLECT_GCC_OPTIONS='-B' './' '-v' '-flto' '-O2' '-static' '-mtune=generic'
'-march=x86-64'
/usr/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/as -v
-o /tmp/ccYNIbg4.o /tmp/ccgxROxd.s
GNU assembler version 2.30 (x86_64-w64-mingw32) using BFD version (GNU
Binutils) 2.30
COMPILER_PATH=./:/usr/libexec/gcc/x86_64-w64-mingw32/8.3.0/:/usr/libexec/gcc/x86_64-w64-mingw32/8.3.0/:/usr/libexec/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/8.3.0/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/
LIBRARY_PATH=./:/usr/lib/gcc/x86_64-w64-mingw32/8.3.0/:/usr/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/lib/../lib/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib/:/usr/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/lib/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/
COLLECT_GCC_OPTIONS='-B' './' '-v' '-flto' '-O2' '-static' '-mtune=generic'
'-march=x86-64'
/usr/libexec/gcc/x86_64-w64-mingw32/8.3.0/collect2 -plugin
/usr/libexec/gcc/x86_64-w64-mingw32/8.3.0/liblto_plugin.so
-plugin-opt=/usr/libexec/gcc/x86_64-w64-mingw32/8.3.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccg7K7YU.res -plugin-opt=-pass-through=-lmingw32
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh
-plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex
-plugin-opt=-pass-through=-lmsvcrt -plugin-opt=-pass-through=-lpthread
-plugin-opt=-pass-through=-ladvapi32 -plugin-opt=-pass-through=-lshell32
-plugin-opt=-pass-through=-luser32 -plugin-opt=-pass-through=-lkernel32
-plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lmoldname
-plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt -flto
--sysroot=/usr/x86_64-w64-mingw32/sys-root -m i386pep -Bstatic
/usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib/crt2.o
/usr/lib/gcc/x86_64-w64-mingw32/8.3.0/crtbegin.o -L.
-L/usr/lib/gcc/x86_64-w64-mingw32/8.3.0
-L/usr/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/lib/../lib
-L/usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib
-L/usr/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/lib
-L/usr/x86_64-w64-mingw32/sys-root/mingw/lib -v /tmp/ccYNIbg4.o -lstdc++
-lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt -lpthread -ladvapi32
-lshel
[Bug ld/24302] When DF_BIND_NOW the dt_tlsdesc_got should not be used
https://sourceware.org/bugzilla/show_bug.cgi?id=24302 Tao Wang changed: What|Removed |Added Severity|normal |critical --- Comment #1 from Tao Wang --- Can anyone have a look at this 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/24319] Compressed / uncompressed debug info confusion in BFD
https://sourceware.org/bugzilla/show_bug.cgi?id=24319 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com, ||nickc at redhat dot com --- Comment #1 from Alan Modra --- > Section '.debug_info' has an invalid size: 0x651b8e4 This bug was introduced by Nick's patch for pr2005. Comparing section size with file size is just 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 binutils/24321] Objcopy "--only-keep-debug" generates Bad Offset in LOAD sections for lld built binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=24321 Manoj Gupta changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from Manoj Gupta --- Here is the problem: --only-keep-debug is supposed to preserve the section headers. But it is not doing so. Our tooling and public tools like Linux perf relies on section headers in splitdebug files to match original binary. Linking to the documentation of --only-keep-debug in objcopy at https://sourceware.org/binutils/docs/binutils/objcopy.html where it says that sections headers are preserved. " --only-keep-debug Strip a file, removing contents of any sections that would not be stripped by --strip-debug and leaving the debugging sections intact. In ELF files, this preserves all note sections in the output. Note - the section headers of the stripped sections are preserved, including their sizes, but the contents of the section are discarded. The section headers are preserved so that other tools can match up the debuginfo file with the real executable, even if that executable has been relocated to a different address space. " Note: Sorry about causing the in --keep-debug". I just wanted to illustrate that eu-strip preserves the headers correctly. eu-strip however does not support --only-keep-debug" and has a different way of generating splitdebug files which is via "--kep-debug" -f option. I am NOT using "--keep-debug" option with GNU strip when generating the splitdebug 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 binutils/24321] Objcopy "--only-keep-debug" generates Bad Offset in LOAD sections for lld built binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=24321 Manoj Gupta changed: What|Removed |Added CC||ruiu 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 binutils/24321] Objcopy "--only-keep-debug" generates Bad Offset in LOAD sections for lld built binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=24321 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Alan Modra --- Why do you think file offset for --only-keep-debug matters? From what you've written you seem to be confusing --only-keep-debug with --strip-debug. They are very different options. -- 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/24321] New: Objcopy "--only-keep-debug" generates Bad Offset in LOAD sections for lld built binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=24321 Bug ID: 24321 Summary: Objcopy "--only-keep-debug" generates Bad Offset in LOAD sections for lld built binaries Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: manojgupta at google dot com Target Milestone: --- We discovered that objcopy creates bad Offsets in LOAD section when generating split-debug files for lld built binaries. This is breaking tools e.g Linux Perf and more tools that rely on the splitdebug file for symbolization. The shared file has a tblgen binary that was built with LLD. https://drive.google.com/file/d/1PTlbzG7nqdu_TLRlpMdKasuBcG0r0LIu/view?usp=sharing Type Offset VirtAddr PhysAddr $ readelf -l tblgen/tblgen|grep LOAD LOAD 0x 0x0020 0x0020 LOAD 0x00722000 0x00922000 0x00922000 # Generate a split-debug debug info file with objcopy $objcopy --only-keep-debug tblgen tblgen.dbg $ readelf -l tblgen.dbg|grep LOAD LOAD 0x 0x0020 0x0020 LOAD 0x1000 0x00922000 0x00922000 The Offset field for second LOAD entry is BAD, it should have been 0x00722000. If I use eu-strip from elfutils, the offsets are correct. $ eu-strip --strip-debug tblgen -f tblgen.debug $ readelf -l tblgen.debug |grep LOAD LOAD 0x 0x0020 0x0020 LOAD 0x00722000 0x00922000 0x00922000 -- 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/24321] Objcopy "--only-keep-debug" generates Bad Offset in LOAD sections for lld built binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=24321 Manoj Gupta changed: What|Removed |Added CC||amodra at gmail dot com, ||manojgupta 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 binutils/24319] Compressed / uncompressed debug info confusion in BFD
https://sourceware.org/bugzilla/show_bug.cgi?id=24319 Hadrien Grasland changed: What|Removed |Added CC||hadrien.grasland 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/24319] New: Compressed / uncompressed debug info confusion in BFD
https://sourceware.org/bugzilla/show_bug.cgi?id=24319 Bug ID: 24319 Summary: Compressed / uncompressed debug info confusion in BFD Product: binutils Version: 2.32 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: hadrien.grasland at gmail dot com Target Milestone: --- A project which I work on recently started experimenting with splitting and compressing debug info. The "splitting" part works perfectly, but unfortunately the "compressing" part seems to confuse some BFD-based DWARF readers such as objdump or the perf profiler in --call-graph=dwarf mode. This is the kind of commands we are using to split and compress debug info: $ objcopy --only-keep-debug --compress-debug-sections $ objcopy --strip-unneeded -R .comment -R .GCC.command.line -R .note.gnu.gold-version Now, my problem is that if I try to profile a binary that links to libraries whose debug info was split like this using `perf record --call-graph=dwarf`, it quickly becomes apparent at `perf report` time that something strange is happening inside of BFD: BFD: DWARF error: found dwarf version '4113', this reader only handles version 2, 3, 4 and 5 information BFD: DWARF error: found dwarf version '20817', this reader only handles version 2, 3, 4 and 5 information BFD: DWARF error: found dwarf version '65361', this reader only handles version 2, 3, 4 and 5 information BFD: DWARF error: found dwarf version '49675', this reader only handles version 2, 3, 4 and 5 information BFD: DWARF error: found dwarf version '22998', this reader only handles version 2, 3, 4 and 5 information BFD: DWARF error: found dwarf version '2259', this reader only handles version 2, 3, 4 and 5 information BFD: DWARF error: found dwarf version '23499', this reader only handles version 2, 3, 4 and 5 information BFD: DWARF error: found dwarf version '13811', this reader only handles version 2, 3, 4 and 5 information BFD: DWARF error: found dwarf version '29659', this reader only handles version 2, 3, 4 and 5 information [ ... abridged ... ] It seems pretty clear to me that during this `perf report` run, BFD is trying to decode as a DWARF version number a piece of data which is not a DWARF version number. I'm not 100% sure what it is, but since the setup works when I split the DWARF info without compressing it, my guess is that BFD is trying to decode compressed DWARF data without uncompressing it first. Now, perf is quite a complex beast, so I tried to narrow down the source of the problem. Given that the error comes from calls to BFD from perf, it seems to me that at least one of following statements must be true : 1. BFD is doing something wrong. 2. Perf is using BFD incorrectly. One way to figure out if statement #1 is true is to try to reproduce fishy behavior with a simpler BFD-based tool like objdump. This is the track which I have been following so far. Indeed, if I point objdump at the split debug info for one of the libraries that I am using, it already says rather strange things about its DWARF contents : $ ls -lh development.strip-comp/Linux_x86_64/opt/lib/.debug/libG4geometry.so.dbg -r--r--r-- 1 hadrien users 55M Mar 11 11:52 development.strip-comp/Linux_x86_64/opt/lib/.debug/libG4geometry.so.dbg $ objdump --dwarf=info --dwarf-depth=1 --dwarf-check development.strip-comp/Linux_x86_64/opt/lib/.debug/libG4geometry.so.dbg development.strip-comp/Linux_x86_64/opt/lib/.debug/libG4geometry.so.dbg: file format elf64-x86-64 Section '.debug_info' has an invalid size: 0x651b8e4. If I got my hex conversion right, that error message is speaking aboug a .debug_info which is 100MB large inside of a file which is 55MB large. I can see how that would be a problem. Since the error message mentioned a bad section size, I tried to look at the corresponding region of the ELF section table using objdump: $ objdump -h development.strip-comp/Linux_x86_64/opt/lib/.debug/libG4geometry.so.dbg development.strip-comp/Linux_x86_64/opt/lib/.debug/libG4geometry.so.dbg: file format elf64-x86-64 Sections: Idx Name Size VMA LMA File off Algn [ ... abridged ... ] 26 .debug_aranges 0001d310 0218 2**4 CONTENTS, READONLY, DEBUGGING 27 .debug_info 0651b8e4 6268 2**0 CONTENTS, READONLY, DEBUGGING 28 .debug_abbrev 00171be7 027fe1c8 2**0 CONTENTS, READONLY, DEBUGGING [ ... abridged ... ] At least the reported size of .debug_info was consistent between the two invocations. However, I was surprised to see that file_offset(.debug_info) + size(.debug_info) >> file_offset(.debug_abbrev). I'm not an ELF / DWARF expert, but it seems to
[Bug ld/24267] ld discards a symbol with -flto and -static
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 --- Comment #21 from Martin Liška --- (In reply to H.J. Lu from comment #20) > (In reply to Martin Liška from comment #19) > > H.J. : Can you please help me how to find a place which makes a real > > decision about which BFD (object) will be used for each symbol? > > Is there a way to easily reproduce it on Fedora 29? I guess so, you'll need to install cross compiler, linker, etc.: https://fedoraproject.org/wiki/MinGW/Tutorial https://fedora.pkgs.org/27/fedora-x86_64/mingw64-gcc-7.2.0-1.fc27.x86_64.rpm.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
