[Bug binutils/29075] objdump -S does not support debuginfod
https://sourceware.org/bugzilla/show_bug.cgi?id=29075 --- Comment #2 from Frank Ch. Eigler --- It does load the debuginfo files, but not the sources (objdump -S). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29075] objdump -S does not support debuginfod
https://sourceware.org/bugzilla/show_bug.cgi?id=29075 --- Comment #8 from Frank Ch. Eigler --- (maybe nickc's confusion was in thinking that the debuginfo download would include sources, as if they were colocated in an rpm, but it doesn't!) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29075] objdump -S does not support debuginfod
https://sourceware.org/bugzilla/show_bug.cgi?id=29075 --- Comment #14 from Frank Ch. Eigler --- Could objdump preemptively call some debuginfod-calling function - any one - in order to prefetch debuginfo for options like -S? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29075] objdump -S does not support debuginfod
https://sourceware.org/bugzilla/show_bug.cgi?id=29075 --- Comment #16 from Frank Ch. Eigler --- Sorry about the confusion, it was mine. Yeah, libbfd.so's dependencies are small, adding debuginfod (=> libcurl) would make it rather larger. OTOH elfutils-libs are on systems already, so the dependencies would not make system install images larger. As an architectural question, I suspect it'd be more of an objdump side change rather than a bfd one, given that bfd doesn't deal with source code. (OTOH bfd/opencls.c has debuginfod-analogous lookup (hard-coding the /usr/lib/.build-id/XXX convention). It could fall back to a debuginfod query via spawning an external debuginfod-find process, if the EXTRA_DEBUG_ROOT1 searches fail. Any idea why we thought putting the code into binutils/dwarf.c instead was the right place for the hook?) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29517] DWARF subprograms output by gas-2.39 have a 'void' return type
https://sourceware.org/bugzilla/show_bug.cgi?id=29517 --- Comment #3 from Frank Ch. Eigler --- (lgtm on paper!) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29993] New: objcopy --merge-notes slow for large .so with many annobin notes
https://sourceware.org/bugzilla/show_bug.cgi?id=29993
Bug ID: 29993
Summary: objcopy --merge-notes slow for large .so with many
annobin notes
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: fche at redhat dot com
Target Milestone: ---
A modern firefox build includes construction of a 3.9GB libxul.so (including
debuginfo) on x86-64. On a f37 toolchain, readelf -S reports
[30] .gnu.build.a[...] NOTE 093022c8 088cef2c
076734c8 0 0 4
i.e., 118MB of .gnu.build.attributes, of some 4 million entries.
The fedora rpm build process includes an
% objcopy --merge-notes libxul.so
stage to gather those together. On a 5GHz machine with ample RAM, this process
takes around ten minutes of 100% cpu time. That's about 1/3rd of the total
build time for the package.
objcopy.c's merge copy seems to be responsible. There is a
doubly nested loop over the notes, resulting in O(n**2) complexity.
2406 for (pnote = pnotes; pnote < pnotes_end; pnote ++)
2407 {
[...]
2426 /* Rule 2: Check to see if there is an identical previous note.
*/
2427 for (iter = 0, back = pnote - 1; back >= pnotes; back --)
2428 {
2429 if (is_deleted_note (back))
2430 continue;
Please consider improving the algorithm's performance on this sort of large
dataset.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/29993] objcopy --merge-notes slow for large .so with many annobin notes
https://sourceware.org/bugzilla/show_bug.cgi?id=29993 --- Comment #5 from Frank Ch. Eigler --- I have not previously looked into the annotation notes in great detail, so am working from a tyro understanding of https://fedoraproject.org/wiki/Toolchain/Watermark . Please excuse my naivite with the following: - The "merging the notes, following rules must be observed" list of that wiki page is lacking rationale. Any transformation that meets the specifications set in the previous paragraphs should be fine. - For example, "Preserve any NT_GNU_BUILD_ATTRIBUTE_FUNC notes" can't be right. Previous to --merge-notes, there are millions of these "func" notes in libxul.so, but after, only a few dozen. (Yes, it turns out there are hundreds of thousands of merges occurring, so that inner loop does likely run many more than 16 iterations.) - For example, "Preserve the ordering of the notes" can't be that serious if the previous prose indicates entries cannot be assumed to be sorted by address, nor can the special version tags be assumed to be at the front. So, as for a more efficient merging algorithm, I would explore something like this: 1) First pass: load all the notes of the bfd, sort them by start-address, grouping them into separate lists (by attribute "owner", "value", "type"). This is so that each list consists of exactly those entries that could be merged, based on the entries' address ranges. 2) For each of those note group lists: 2a) Create an output list for the new merged notes in this group. 2b) Iterate entries by address. 2b1) Copy the current entry into the output list. We'll merge others into this one. 2b2) If the next entry adjoins/overlaps this entry, merge the start/end range of the new entry. Try this again for subsequent entries until finding one that does not adjoin/overlap. Mark that next entry as the next one for iteration at step 2b) 3) Write the output lists into the output elf file, replacing the previous .gnu.build.attributes. This should be O(N log N) time algorithm for sorting by address, then O(N) for the actual merging process. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29993] objcopy --merge-notes slow for large .so with many annobin notes
https://sourceware.org/bugzilla/show_bug.cgi?id=29993 --- Comment #9 from Frank Ch. Eigler --- > Yes - I am afraid that the watermark protocol document is a bit out of date, > and its rules for note merging do need to be updated. I'd suggest not over-specifying merging, or specifying merging per se at all. How about only documenting the semantics of the notes for consumers? Any transform that preserves those semantics would be fine. > [...] > With this patch applied I found that merging libxul.so went down from 10.5 > minutes to 5 minutes on my local machine. Not an order of magnitude > improvement I know, but would it be enough for you ? Nice improvement. I'm not in a position to set a goal. I can only suspect that it could be gotten down to a few seconds instead of a few minutes, but dunno whether there are hard constraints. > I am hesitant to rewrite the algorithm entirely because if I get it wrong I > am likely to break the building of other packages - either by corrupting the > notes so that annocheck then complains, or breaking the merge process so > that the rpms do not build or something else. Understood - that comes from being in the honoured place deep within the buildroot. :-) OTOH, it should be possible to mass-build a variety of packages, run a new merger, and test it against some older and more current annocheck consumers, to confirm no change. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26301] [2.36 Regression] Incorrect detection of libdebuginfod
https://sourceware.org/bugzilla/show_bug.cgi?id=26301 Frank Ch. Eigler changed: What|Removed |Added CC||fche at redhat dot com --- Comment #8 from Frank Ch. Eigler --- A workaround is installing elfutils-debuginfod-client-devel*.i686. Is that not pretty normal for cross-compiling environments? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26595] New: objdump/readelf debuginfod client not invoked for altdebug dwz file
https://sourceware.org/bugzilla/show_bug.cgi?id=26595 Bug ID: 26595 Summary: objdump/readelf debuginfod client not invoked for altdebug dwz file Product: binutils Version: 2.34 Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: amerey at redhat dot com, woodard at redhat dot com Target Milestone: --- The debuginfod client code in objdump is appropriately invoked in --dwarf=follow-links mode, but it seems only for the main detached .debug file, but not its dependent .dwz file. To reproduce on f32: % export DEBUGINFOD_URLS=https://debuginfod.elfutils.org/ % rm -rf ~/.cache/debuginfod_client % objdump --dwarf=follow-links -W /lib64/libboost_system.so.1.69.0 [observe incomplete data, observe reference to dwz buildid] % ls ~/.cache/debuginfod_client [observe only main boost_system .debug file, not dwz one] Same behaviour with readelf: % readelf --debug-dump=follow-links -w /lib64/libboost_system.so.1.69.0 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26595] objdump/readelf debuginfod client not invoked for altdebug dwz file
https://sourceware.org/bugzilla/show_bug.cgi?id=26595 --- Comment #2 from Frank Ch. Eigler --- confirmed working with objdump, thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/10238] Gold linker does not resolve symbols using indirect dependencies
-- What|Removed |Added CC||fche at redhat dot com http://sourceware.org/bugzilla/show_bug.cgi?id=10238 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/10238] Gold linker does not resolve symbols using indirect dependencies
--- Additional Comments From fche at redhat dot com 2009-10-12 16:10 --- IMO, ld's automagic searching is a good thing. Asking a program to enumerate all the indirect dependencies of shared libraries is a burden that they may not be equipped to carry. How do you envision this be automatable? readelf to get DT_NEEDED notes, and form that synthesize -lMMM calls? It is as if header files didn't #include their own dependencies, forcing main.c to do include a topological sorted list of all headers. It's possible but unfair. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10238 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/10238] Gold linker does not resolve symbols using indirect dependencies
--- Additional Comments From fche at redhat dot com 2009-10-12 23:53
---
I'm confused about whether gold's lack of DT_NEEDED resolution is
intended to affect only pure-indirect or merely mixed-direct-indirect
dependencies. Specifically:
liba { int a() { return b(); } }
libb { int b() { return 0; } }
main() { a() } -la # libb a pure indirect dependency
- versus -
main() { b() } -la # libb a direct dependency
If the latter, I'm more sympathetic to the desire to have a program state
its own direct depencencies.
If the former, I'm more sympathetic to a program not having to know all the
indirect dependencies of all of its shared libraries.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10238
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
