[Toybox] Implementing ldd.

enh enh at google.com
Thu Jan 13 11:20:18 PST 2022


TL;DR: unless you're writing your own dynamic linker, i'm not sure why
you'd write an ldd?

personally i don't think a readelf-based ldd makes much sense? there
are a ton of weird special cases that mean you really do need the
"suck it and see" implementation --- bionic already just has a
one-line shell script that passes an argument to the dynamic linker
(and i think glibc and musl work this way too).

which isn't to say that the question doesn't sometimes come up of "i'd
like to print the transitive closure of DT_NEEDEDs *on the host*" but
note that that's *not* the same thing, and so even if someone does
write that, it probably deserves a different tool name and a big "note
that your run-time mileage may vary wildly".

On Thu, Jan 13, 2022 at 11:14 AM Rob Landley <rob at landley.net> wrote:
>
> In theory ldd is a subset of readelf, so we've already got most of the code. In
> practice, the OTHER thing it does is try to dlopen() each library so it can get
> a path and address out of /proc/self/maps.
>
> The problem is if you're statically linked, bionic links in a dlopen() stub
> return ing NULL. Which makes sense because you couldn't USE the dlopen() result
> because of the old "now we have two heap pointers and if you malloc() from the
> dynamic one and free() into the static one and you've cross-linked your heaps"
> problem, but all I'm trying to do is get the path to the file and the preferred
> load address.
>
> Not entirely sure the right thing to do here. This is one of those "almost
> entirely trivial, except for the land mine" things. I guess I can just print the
> library name from the ELF info but not the => part when dlopen() returns null?
>
> Rob
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net



More information about the Toybox mailing list