Bug 2102778

(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).