This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] elf: Remove pldd (BZ#18035)
On 4/10/19 4:41 PM, Adhemerval Zanella wrote:
On 10/04/2019 17:17, Carlos O'Donell wrote:
On 4/10/19 3:04 PM, Adhemerval Zanella wrote:
As reported in bugzilla itself and on man-pages [1] it has been
broken since 2.19. Also, its design tie glibc internal definition
by duplicate struct layouts and dynamic loader objects.
I have a sustained objection to removing pldd.
Have we looked into why it's broken?
I will take a second look, but my wildly guess is most likely some
internal linker interface has drift from pldd internal definitions
and when it tries to poke on process memory it reads invalid memory.
OK, please share what you find if you think we need to do this some
other way.
I'm happy to add a test-in-container runtime test for it so we can
see breakage when it happens.
It matches the same Solaris tool pldd, and is a useful utility.
I agree it is useful, but the same functionally can be provided with
different tools and/or kernel facilities. The advantage I see that
pldd might have it is suppose to poke on internal glibc data structures
and get the loaded dynamic shared objects without relying on additional
kernel information.
Right.
Could we link pldd against ld.so and export an external private interface
that allows pldd to use ld.so to read another ld.so's memory?
We always assume pldd and ld.so match the system glibc, so this would
remove the problem that we're relying on duplicate information.
In eu-ldd this was much easier because I only needed to read ELF, and so
that's well structured, but I do need to duplicate a lot of ld.so logic,
but I found that a win, in that eu-ldd ends up being a clean-room
implementation of the loading logic for testing comparison.
pldd is not that.
This requires python in base runtime, and might not be on a production
container instance.
Ok, the question I have is whether we want to make pldd still poke the loader
internal data structures directly using /proc/<pid>/mem plus ptrace or if we
can use a simplified version by parsing /proc/<pid>/maps (as lsof does).
For latter, why we can't use use lsof instead? Do we really need to provide
a similar tool (but will less features)?
lsof is a completely different installed package on most rpm derivative distros.
While pldd is in glibc-common and always installed.
Having a smaller tool that provides a quick way to check libs in the process.
I don't think the maintenance cost outweights the benefit (yet).
I think we actually need *more* tooling like this, like lari:
https://docs.oracle.com/cd/E36784_01/html/E36870/lari-1.html
All of which are useful in debugging production issues on production systems
that don't always have all the tools you want available, but have a small
set of sanity-checking tools.
Packaging a minimum set of useful tools with glibc ensures that the project
as a whole delivers what is required to inspect and debug processes that use
glibc and act as examples for what we believe is required to debug glibc-linked
proccesses.
In summary I don't think we're at the tipping point of throwing away pldd.
--
Cheers,
Carlos.