Description of problem: glibc's ld-2.28.so & ld-linux-2.28.so contain debug information. This was not the case in prior versions of glibc. (Checked 2.28-164.el8.) This is not the case for any other shared objects in glibc. I believe it is not intentional and is a bug. Version-Release number of selected component (if applicable): 2.28-189.1.el8 2.28-189.5.el_6 How reproducible: 100% Steps to Reproduce: 1. readelf -S /lib64/ld-2.28.so | fgrep .debug_ 2. readelf -S /lib/ld-2.28.so | fgrep .debug_ 3. Actual results: [26] .debug_aranges PROGBITS 0000000000000000 0002f550 [27] .debug_info PROGBITS 0000000000000000 00030730 [28] .debug_abbrev PROGBITS 0000000000000000 00066fc1 [29] .debug_line PROGBITS 0000000000000000 0006d4f5 [30] .debug_str PROGBITS 0000000000000000 0009bbba [31] .debug_loc PROGBITS 0000000000000000 000a45a1 [32] .debug_ranges PROGBITS 0000000000000000 000ebd8b [26] .debug_aranges PROGBITS 00000000 02ed10 000c98 00 0 0 8 [27] .debug_info PROGBITS 00000000 02f9a8 02e6a5 00 0 0 1 [28] .debug_abbrev PROGBITS 00000000 05e04d 0060dd 00 0 0 1 [29] .debug_line PROGBITS 00000000 06412a 02fe1e 00 0 0 1 [30] .debug_str PROGBITS 00000000 093f48 008b41 01 MS 0 0 1 [31] .debug_loc PROGBITS 00000000 09ca89 02961e 00 0 0 1 [32] .debug_ranges PROGBITS 00000000 0c60a8 006f68 00 0 0 8 Expected results: (no output) Additional info:
(In reply to Todd Allen from comment #0) > Description of problem: > glibc's ld-2.28.so & ld-linux-2.28.so contain debug information. > This was not the case in prior versions of glibc. (Checked 2.28-164.el8.) > This is not the case for any other shared objects in glibc. > I believe it is not intentional and is a bug. It's a deliberate change, part of bug 1661513. We are removing more debugging information and symbol tables than before, so the installation size is actually smaller overall. We are keeping the debugging information for ld.so, so that tools like Systemtap can use it to traverse internal data structures, for example to emulate access to TLS variables. Do you see any adverse impact from this change?
I saw that change, but it talked about stripping binaries, which seemed irrelevant to ld-2.28.so, and also the exact opposite of what's happening here: *not* stripping a shared object. Anyway, the nature of our adverse impact: I develop and maintain a proprietary debugger (Concurrent Real-Time's NightView). In general, our debugger stops a new process at _dl_debug_state so that it can snoop around to find shared objects that are loaded from the dynamic section of the executable. After that, it generally shows the user their main function (or other language-appropriate location). But we have a heuristic in case it were able to find the debug information for ld-{whatnot}.so. In the past, that meant that a customer had installed it intentionally. So, if the debugger was able to find that debug information, we deduced that the customer might care about it, and so the debugger instead presents the user as being at _dl_debug_state itself. That's happening all the time now, after this change. I can certainly imagine that no one would guess that adding extra debug info would cause problems for anyone. It is for us. Not insurmountable, but if this change is here to stay, it probably means we need to throw out this heuristic. :(
Hmm, looks like I wrote al long-ish update yesterday, but apparently didn't hit Save Changes. 8-( Does your debugger not follow GNU debuglink references to separated debuginfo? It's not uncommon to install glibc debuginfo when working on C/C++ software, and this makes debuginfo for ld.so available as well. If you fix the debugger's heuristic, that would improve support for that scenario as well (always assuming that separated debuginfo works at all, but without that, debugging is really no joy—note that we lost the debuginfo link for the shared objects, that's something we will have to fix). I'm closing this as CLOSED/NOTABUG because it is an intended change. If you disagree with that, I suggest you open a support ticket at <https://access.redhat.com/support/cases/>, so that this can be captured properly. Thanks.
Yes, the debugger supports separated debuginfo (a couple different schemes too...) That's what I was talking about: If the debuginfo's are present, it surmises that the user cares about debugging things in glibc... such as _dl_debug_state, etc. If the debuginfo's are absent, it assumes they care about getting straight to main (or whatnot).
(In reply to Todd Allen from comment #4) > Yes, the debugger supports separated debuginfo (a couple different schemes > too...) That's what I was talking about: If the debuginfo's are present, it > surmises that the user cares about debugging things in glibc... such as > _dl_debug_state, etc. If the debuginfo's are absent, it assumes they care > about getting straight to main (or whatnot). My point was that this is in conflict with our distribution tooling, which typically recommends installation of debuginfo for run-time dependencies, so glibc-debuginfo is often present during development/debugging. And that has always included debuginfo for ld.so (separated and now non-separated).