[Bug tools/24795] New: eu-unstrip doesn't recognize MIPS_DWARF as debug section
https://sourceware.org/bugzilla/show_bug.cgi?id=24795 Bug ID: 24795 Summary: eu-unstrip doesn't recognize MIPS_DWARF as debug section Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: tools Assignee: unassigned at sourceware dot org Reporter: vries at gcc dot gnu.org CC: elfutils-devel at sourceware dot org Target Milestone: --- Consider the section header table of a hello world exec on debian 7 MIPS: ... $ readelf -S hello There are 42 section headers, starting at offset 0xcf4: Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .interp PROGBITS00400154 000154 0d 00 A 0 0 1 [ 2] .note.ABI-tag NOTE00400164 000164 20 00 A 0 0 4 [ 3] .reginfo MIPS_REGINFO00400184 000184 18 18 A 0 0 4 [ 4] .note.gnu.build-i NOTE0040019c 00019c 24 00 A 0 0 4 [ 5] .dynamic DYNAMIC 004001c0 0001c0 f8 08 A 8 0 4 [ 6] .hash HASH004002b8 0002b8 40 04 A 7 0 4 [ 7] .dynsym DYNSYM 004002f8 0002f8 b0 10 A 8 1 4 [ 8] .dynstr STRTAB 004003a8 0003a8 85 00 A 0 0 1 [ 9] .gnu.version VERSYM 0040042e 00042e 16 02 A 7 0 2 [10] .gnu.version_rVERNEED 00400444 000444 20 00 A 8 1 4 [11] .rel.plt REL 00400464 000464 08 08 A 7 13 4 [12] .init PROGBITS0040046c 00046c 68 00 AX 0 0 4 [13] .plt PROGBITS004004e0 0004e0 30 00 AX 0 0 32 [14] .text PROGBITS00400510 000510 000290 00 AX 0 0 16 [15] .MIPS.stubs PROGBITS004007a0 0007a0 20 00 AX 0 0 4 [16] .fini PROGBITS004007c0 0007c0 38 00 AX 0 0 4 [17] .rodata PROGBITS00400800 000800 20 00 A 0 0 16 [18] .eh_frame PROGBITS00400820 000820 04 00 A 0 0 4 [19] .ctorsPROGBITS00410824 000824 08 00 WA 0 0 4 [20] .dtorsPROGBITS0041082c 00082c 08 00 WA 0 0 4 [21] .jcr PROGBITS00410834 000834 04 00 WA 0 0 4 [22] .data PROGBITS00410840 000840 10 00 WA 0 0 16 [23] .rld_map PROGBITS00410850 000850 04 00 WA 0 0 4 [24] .got.plt PROGBITS00410854 000854 0c 00 WA 0 0 4 [25] .got PROGBITS00410860 000860 28 04 WAp 0 0 16 [26] .sdataPROGBITS00410888 000888 04 00 WAp 0 0 4 [27] .bss NOBITS 00410890 00088c 10 00 WA 0 0 16 [28] .comment PROGBITS 00088c 39 01 MS 0 0 1 [29] .pdr PROGBITS 0008c8 60 00 0 0 4 [30] .debug_arangesMIPS_DWARF 000928 20 00 0 0 1 [31] .debug_info MIPS_DWARF 000948 88 00 0 0 1 [32] .debug_abbrev MIPS_DWARF 0009d0 3f 00 0 0 1 [33] .debug_line MIPS_DWARF 000a0f 64 00 0 0 1 [34] .debug_frame MIPS_DWARF 000a74 2c 00 0 0 4 [35] .debug_strMIPS_DWARF 000aa0 95 01 MS 0 0 1 [36] .debug_locMIPS_DWARF 000b35 2c 00 0 0 1 [37] .gnu.attributes LOOS+ff5 000b61 10 00 0 0 1 [38] .mdebug.abi32 PROGBITS 000b71 00 00 0 0 1 [39] .shstrtab STRTAB 000b71 000181 00 0 0 1 [40] .symtab SYMTAB 001384 000550 10 41 58 4 [41] .strtab STRTAB 0018d4 000273 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) ... After doing: ... eu-strip hello -o hello.stripped -f hello.debug ... we have: ... $ readelf -S hello.debug | grep NOBITS [ 1] .interp NOBITS 00400154 000154 0d 00 A 0 0 1 [ 3] .reginfo NOBITS 00400184 000174 18 18 A 0 0 4 [ 5] .dynamic NOBITS 004001c0 000198 f8 08 A 8 0 4 [ 6] .hash NOBITS 004002b8 000198 40 04 A 7 0 4 [ 7] .dynsym NOBITS 004002f8 000198 b0 10 A 8 1 4 [ 8] .dynstr NOBITS 004003a8 000198 85 0
[Bug tools/24795] eu-unstrip doesn't recognize MIPS_DWARF as debug section
https://sourceware.org/bugzilla/show_bug.cgi?id=24795 --- Comment #2 from Tom de Vries --- (In reply to Mark Wielaard from comment #1) > (In reply to Tom de Vries from comment #0) > > Consider the section header table of a hello world exec on debian 7 MIPS: > > BTW. Isn't Debian 7 really old? > Yep, initial release 2013. > > This is with an old eu-strip (0.152), but I don't manage building from git > > for now, > > See the README: > > To build a git checkout do: >autoreconf -i -f && \ >./configure --enable-maintainer-mode && \ >make && make check > Ah, ok. > Please let us know what issues you are seeing. > I tried elfutils-latest.tar.bz2 instead, and ran into the use of aligned_alloc, which is supported starting glibc v2.16, while debian 7 has glibc v2.13. > > so atm I cannot say whether this is fixed on trunk or not. > > It isn't. elfutils doesn't have a MIPS backend and so knows nothing about > special MIPS ELF constructs. Ah, I see indeed at https://sourceware.org/elfutils/ that mips is missing: ... Included backends for machine specific ELF handling: aarch64 alpha arm bpf i386 ia64 m68k ppc ppc64 s390 s390x sh sparc sparc64 tilegx x32 x86_64 ... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/24809] New: eu-unstrip to drop SECTION symbols if section .note.gnu.gold-version present
https://sourceware.org/bugzilla/show_bug.cgi?id=24809
Bug ID: 24809
Summary: eu-unstrip to drop SECTION symbols if section
.note.gnu.gold-version present
Product: elfutils
Version: unspecified
Status: NEW
Severity: enhancement
Priority: P2
Component: tools
Assignee: unassigned at sourceware dot org
Reporter: vries at gcc dot gnu.org
CC: elfutils-devel at sourceware dot org
Target Milestone: ---
Consider a hello world with debug info, linked using gold:
...
$ gcc hello.c -g -fuse-ld=gold -o hello
...
Now say we strip using objcopy, and then unstrip:
...
$ objcopy --only-keep-debug hello hello.debug
$ objcopy --strip-debug hello hello.stripped
$ eu-unstrip hello.stripped hello.debug -o hello.unstripped
...
Interestingly, the unstripped exec is larger than the original:
...
$ ls -la
-rwxr-xr-x 1 vries users 14104 15 jul 12:34 hello
-rwxr-xr-x 1 vries users 11528 15 jul 12:34 hello.debug
-rwxr-xr-x 1 vries users 8760 15 jul 12:34 hello.stripped
-rwxr-xr-x 1 vries users 14896 15 jul 12:34 hello.unstripped
...
Comparing section sizes, we get:
...
$ readelf -S -W hello | grep ']'| sed 's/\[ /[/' | egrep -v 'NULL|Name' | awk
'{print $2, $6}' > SIZE.1
$ readelf -S -W hello.unstripped | grep ']'| sed 's/\[ /[/' | egrep -v
'NULL|Name' | awk '{print $2, $6}' > SIZE.2
$ diff -u SIZE.1 SIZE.2
--- SIZE.1 2019-07-15 12:43:14.495608629 +0200
+++ SIZE.2 2019-07-15 12:43:07.743655249 +0200
@@ -35,6 +35,6 @@
.debug_ranges 80
.debug_loc 00013e
.note.gnu.gold-version 1c
-.symtab 0003c0
-.strtab 000213
+.symtab 000720
+.strtab 0001cf
.shstrtab 000190
...
That is, the .strtab section is slightly smaller, but the .symtab section
significantly larger.
The difference is because of the SECTION symbols, which ld normally adds, but
gold doesn't. However, objcopy adds them nevertheless:
...
$ readelf -s hello | grep -c SECTION
0
$ readelf -s hello.debug | grep -c SECTION
37
$ readelf -s hello.stripped | grep -c SECTION
30
$ readelf -s hello.unstripped | grep -c SECTION
37
...
It would be good if eu-unstrip could recognize the fact that the exec was
produced using gold (there seems to be a section .note.gnu.gold-version) and
drop those symbols (and likewise, objcopy should probably do the same).
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/24809] objcopy to not add SECTION symbols if section .note.gnu.gold-version present
https://sourceware.org/bugzilla/show_bug.cgi?id=24809 Tom de Vries changed: What|Removed |Added Component|tools |binutils Version|unspecified |2.33 (HEAD) Product|elfutils|binutils Summary|eu-unstrip to drop SECTION |objcopy to not add SECTION |symbols if section |symbols if section |.note.gnu.gold-version |.note.gnu.gold-version |present |present --- Comment #2 from Tom de Vries --- (In reply to Mark Wielaard from comment #1) > I can replicate this if I use objcopy to produce the hello.debug and > hello.stripped binaries. But why don't you just use eu-strip? > I think the idea here is to have the tools from the two "products" to play nice together. > Doing: > $ eu-strip -f hello.debug -o hello.stripped hello > $ eu-unstrip hello.stripped hello.debug -o hello.unstripped > > Produces: > $ ls -la > -rwxrwxr-x. 1 mark mark 10416 Jul 15 14:50 hello > -rw-rw-r--. 1 mark mark92 Jul 15 14:50 hello.c > -rwxrwxr-x. 1 mark mark 6840 Jul 15 14:52 hello.debug > -rwxrwxr-x. 1 mark mark 6488 Jul 15 14:52 hello.stripped > -rwxrwxr-x. 1 mark mark 10416 Jul 15 14:52 hello.unstripped > > $ readelf -s hello.debug | grep -c SECTION > 0 > $ readelf -s hello.stripped | grep -c SECTION > 0 > $ readelf -s hello.unstripped | grep -c SECTION > 0 > > Which seems much more reasonable than what objcopy does. > Right, I noticed that. > I am not sure eu-unstrip should remove extra stuff objcopy adds. It seems > that if the user created these bigger than necessary .debug and .stripped > files, then they wanted that for some reason. It seems unwise to second > guess the user. > > If there is a bug, then I think it is simply a bug in objcopy, which can be > prevented by using eu-strip instead. OK, changing product to binutils. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/24809] objcopy to not add SECTION symbols if section .note.gnu.gold-version present
https://sourceware.org/bugzilla/show_bug.cgi?id=24809 --- Comment #5 from Tom de Vries --- (In reply to Nick Clifton from comment #4) > (In reply to cvs-com...@gcc.gnu.org from comment #3) > > The master branch has been updated by Nick Clifton : > > > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git; > > h=48467cb99b04c9d908ce2dd74422c9c3f322ccc3 > > Sorry - this is not a patch for this PR. It was a patch submitted by a > different person called Tom, and I got confused. Doh! Ah I see, thanks for mentioning this. I was confused there for a bit. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/32701] gdb is attempting to write to / and write to rpm's database for no reason.
https://sourceware.org/bugzilla/show_bug.cgi?id=32701 Tom de Vries changed: What|Removed |Added CC||elfutils-devel at sourceware dot o ||rg, vries at gcc dot gnu.org Version|10.1|unspecified Component|gdb |debuginfod Product|gdb |elfutils --- Comment #2 from Tom de Vries --- I think this is related to the make_cache_path function in debuginfod/debuginfod-client.c in elfutils. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/32701] gdb is attempting to write to / and write to rpm's database for no reason.
https://sourceware.org/bugzilla/show_bug.cgi?id=32701 Tom de Vries changed: What|Removed |Added Resolution|FIXED |NOTABUG --- Comment #8 from Tom de Vries --- Reverting to resolved-notabug, assuming the resolved-fixed was an accident. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/27673] New: [debuginfod] Handle source requests for same buildid more efficiently
https://sourceware.org/bugzilla/show_bug.cgi?id=27673 Bug ID: 27673 Summary: [debuginfod] Handle source requests for same buildid more efficiently Product: elfutils Version: unspecified Status: NEW Severity: enhancement Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: vries at gcc dot gnu.org CC: elfutils-devel at sourceware dot org Target Milestone: --- Consider the following debuginfod usage session from gdb (reported in gdb PR27667): ... $ time gdb -batch -q ./mi-sym-info -ex start -ex "interpreter-exec mi 111-symbol-info-functions" > OUTPUT TRYING DEBUGINFO FOR: /data/gdb_versions/devel/system-supplied DSO at 0x77fca000 BUILDID: e77a560007595d823e2c5a34697c0b0ae1ffc767 TOOK: 0.84 seconds RESULT fd: 16 TRYING SOURCE: /home/abuild/rpmbuild/BUILD/gcc-10.2.1+git1331/obj-x86_64-suse-linux/x86_64-suse-linux/libgcc/../../../libgcc/config/i386/sfp-exceptions.c BUILDID: d34928e1b5c7bde5e269e47349ade7369a3efa83 TOOK: 0.601374 seconds RESULT fd: -2 TRYING SOURCE: /home/abuild/rpmbuild/BUILD/gcc-10.2.1+git1331/obj-x86_64-suse-linux/x86_64-suse-linux/libgcc/../../../libgcc/libgcc2.c BUILDID: d34928e1b5c7bde5e269e47349ade7369a3efa83 TOOK: 0.486450 seconds RESULT fd: -2 TRYING SOURCE: /home/abuild/rpmbuild/BUILD/gcc-10.2.1+git1331/obj-x86_64-suse-linux/x86_64-suse-linux/libgcc/../../../libgcc/libgcc2.c BUILDID: d34928e1b5c7bde5e269e47349ade7369a3efa83 TOOK: 0.493712 seconds RESULT fd: -2 TRYING SOURCE: /home/abuild/rpmbuild/BUILD/gcc-10.2.1+git1331/obj-x86_64-suse-linux/x86_64-suse-linux/libgcc/../../../libgcc/libgcc2.c BUILDID: d34928e1b5c7bde5e269e47349ade7369a3efa83 TOOK: 0.487850 seconds RESULT fd: -2 TRYING SOURCE: /home/abuild/rpmbuild/BUILD/gcc-10.2.1+git1331/obj-x86_64-suse-linux/x86_64-suse-linux/libgcc/../../../libgcc/libgcc2.c BUILDID: d34928e1b5c7bde5e269e47349ade7369a3efa83 TOOK: 0.488300 seconds RESULT fd: -2 TRYING SOURCE: /home/abuild/rpmbuild/BUILD/gcc-10.2.1+git1331/obj-x86_64-suse-linux/x86_64-suse-linux/libgcc/../../../libgcc/libgcc2.c BUILDID: 7076274fc469c32fa8f4201f467447da3ad2b6be TOOK: 0.493761 seconds RESULT fd: -2 TRYING SOURCE: /home/abuild/rpmbuild/BUILD/gcc-10.2.1+git1331/obj-x86_64-suse-linux/x86_64-suse-linux/libgcc/../../../libgcc/soft-fp/addtf3.c BUILDID: d34928e1b5c7bde5e269e47349ade7369a3efa83 TOOK: 0.486202 seconds RESULT fd: -2 TRYING SOURCE: /home/abuild/rpmbuild/BUILD/gcc-10.2.1+git1331/obj-x86_64-suse-linux/x86_64-suse-linux/libgcc/../../../libgcc/soft-fp/divtf3.c BUILDID: d34928e1b5c7bde5e269e47349ade7369a3efa83 TOOK: 0.485941 seconds RESULT fd: -2 TRYING SOURCE: /home/abuild/rpmbuild/BUILD/gcc-10.2.1+git1331/obj-x86_64-suse-linux/x86_64-suse-linux/libgcc/../../../libgcc/soft-fp/eqtf2.c BUILDID: d34928e1b5c7bde5e269e47349ade7369a3efa83 TOOK: 0.477989 seconds RESULT fd: -2 TRYING SOURCE: /home/abuild/rpmbuild/BUILD/gcc-10.2.1+git1331/obj-x86_64-suse-linux/x86_64-suse-linux/libgcc/../../../libgcc/soft-fp/extenddftf2.c BUILDID: d34928e1b5c7bde5e269e47349ade7369a3efa83 TOOK: 0.487699 seconds RESULT fd: -2 TRYING SOURCE: /home/abuild/rpmbuild/BUILD/gcc-10.2.1+git1331/obj-x86_64-suse-linux/x86_64-suse-linux/libgcc/../../../libgcc/soft-fp/fixtfdi.c BUILDID: d34928e1b5c7bde5e269e47349ade7369a3efa83 TOOK: 0.488412 seconds RESULT fd: -2 TRYING SOURCE: /home/abuild/rpmbuild/BUILD/gcc-10.2.1+git1331/obj-x86_64-suse-linux/x86_64-suse-linux/libgcc/../../../libgcc/soft-fp/fixtfsi.c BUILDID: d34928e1b5c7bde5e269e47349ade7369a3efa83 TOOK: 0.496897 seconds RESULT fd: -2 TRYING SOURCE: /home/abuild/rpmbuild/BUILD/gcc-10.2.1+git1331/obj-x86_64-suse-linux/x86_64-suse-linux/libgcc/../../../libgcc/soft-fp/floatditf.c BUILDID: d34928e1b5c7bde5e269e47349ade7369a3efa83 TOOK: 0.492576 seconds RESULT fd: -2 TRYING SOURCE: /home/abuild/rpmbuild/BUILD/gcc-10.2.1+git1331/obj-x86_64-suse-linux/x86_64-suse-linux/libgcc/../../../libgcc/soft-fp/floatsitf.c BUILDID: d34928e1b5c7bde5e269e47349ade7369a3efa83 TOOK: 0.477747 seconds RESULT fd: -2 TRYING SOURCE: /home/abuild/rpmbuild/BUILD/gcc-10.2.1+git1331/obj-x86_64-suse-linux/x86_64-suse-linux/libgcc/../../../libgcc/soft-fp/floatunsitf.c BUILDID: d34928e1b5c7bde5e269e47349ade7369a3efa83 TOOK: 0.480452 seconds RESULT fd: -2 TRYING SOURCE: /home/abuild/rpmbuild/BUILD/gcc-10.2.1+git1331/obj-x86_64-suse-linux/x86_64-suse-linux/libgcc/../../../libgcc/soft-fp/getf2.c BUILDID: d34928e1b5c7bde5e269e47349ade7369a3efa83 TOOK: 0.487295 seconds RESULT fd: -2 TRYING SOURCE: /home/abuild/rpmbuild/BUILD/gcc-10.2.1+git1331/obj-x86_64-suse-linux/x86_64-suse-linux/libgcc/../../../libgcc/soft-fp/letf2.c BUILDID: d34928e1b5c7bde5e269e47349ade7369a3efa83 TOOK: 0.479365 seconds RESULT fd: -2 TRYING SOURCE: /home/abuild/rpmbuild/BUILD/gcc-10.2.1+git1331/obj-x86_64-suse-linux/x86_64-suse-linux/libgcc/../../../libgcc/soft-fp/multf3.c BUILDID: d34928e1b5c7bde5e269e47349ade736
[Bug debuginfod/27673] [debuginfod] Handle source requests for same buildid more efficiently
https://sourceware.org/bugzilla/show_bug.cgi?id=27673 Tom de Vries changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0 --- Comment #3 from Tom de Vries --- (In reply to Frank Ch. Eigler from comment #2) > The subject line "handle sources ... from same buildid ... more efficiently" > suggests a caching opportunity. The debuginfod --fdcache-prefetch parameter > is probably the gadget of interest here. The opensuse operators could > experiment with a much larger than default figure. (You can test it locally > by running debuinfod for yourself, against a local set of relevant -debug* > RPMs.) The time it takes for the client to see the response of the server to the request consist of: - time for request to travel to server (latency) - time for server to react to request - time for answer to travel back to client (latency again) I've looked at the documentation of the option fdcache-prefetch, and AFAIU this improves "time for server to react to request". Instead, the focus of this PR is to hide latency (since that's where the majority of the time is spent) by using more bandwidth. Proposal a: debuginfod: - when receiving a source request and ENOENT, send as reply the list of available files for the buildid client: - when receiving a list of available files for a buildid, store it and use it to reply to source requests related to the buildid. That is, if the file is not in the list, reply with -2. Otherwise, send a request to debuginfod, and expect it to succeed. Proposal b: debuginfod: - when receiving a source request, send a package with the sources for that buildid to the client. client: - when receiving a package with the sources for a buildid, store them and use them to reply to source requests related to the buildid. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/27673] [debuginfod] Handle source requests for same buildid more efficiently
https://sourceware.org/bugzilla/show_bug.cgi?id=27673 --- Comment #5 from Tom de Vries --- (In reply to Frank Ch. Eigler from comment #4) > > debuginfod: > > - when receiving a source request and ENOENT, send as reply the list of > > available files for the buildid > > > > client: > > - when receiving a list of available files for a buildid, store it and > > use it to reply to source requests related to the buildid. That is, > > if the file is not in the list, reply with -2. Otherwise, send a > > request to debuginfod, and expect it to succeed. > > Interesting. A more first-class solution could be a new webapi to > enumerate source files: a "/buildid/HEXCODE/sourcelist" query that > returns a structured piece of data. This can be computed by debuginfod > fairly rapidly. The client could cache that and use it to drive a > negative-cache hit on a subsequent source query. Agreed, it would be good to have this kind of functionality available more generically. Then the client (preferably the elfutils client itself using some setting, otherwise the part using the elfutils client) could upon the first source request send a sourcelist request in parallel, to have the latencies of the two requests overlap. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/27673] [debuginfod] Handle source requests for same buildid more efficiently
https://sourceware.org/bugzilla/show_bug.cgi?id=27673 Tom de Vries changed: What|Removed |Added Blocks||27678 Referenced Bugs: https://sourceware.org/bugzilla/show_bug.cgi?id=27678 [Bug 27678] [gdb/symtab] Use debuginfod sourcelist api to test for file existence -- You are receiving this mail because: You are on the CC list for the bug.
