pkg/ldd: filter dependencies without a filesystem path

[florianGla]

Running the interpreter gives results of the following form:

linux-vdso.so.1 => linux-vdso.so.1
libc.so.6 => /usr/lib/libc.so.6
libc.so.6 => /usr/lib/libc.so.6 (0x00007ffe4972d000)
linux-vdso.so.1 => (0x00007ffe4972d000)

In the last example the file path is empty and only the memory address is shown. Those cases should be skipped because the third field is assumed to be a valid file path.

[codecov]

Codecov Report

Base: 74.71% // Head: 74.87% // Increases project coverage by +0.16% 🎉

Coverage data is based on head (0eb7eb9) compared to base (a41bade).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2633      +/-   ##
==========================================
+ Coverage   74.71%   74.87%   +0.16%     
==========================================
  Files         412      412              
  Lines       41649    41651       +2     
==========================================
+ Hits        31117    31188      +71     
+ Misses      10532    10463      -69     

Impacted Files	Coverage Δ
pkg/ldd/ldd_unix.go	80.19% <100.00%> (+0.40%)	⬆️
pkg/acpi/rsdp.go	51.28% <0.00%> (+10.25%)	⬆️
pkg/acpi/raw.go	89.28% <0.00%> (+14.28%)	⬆️
pkg/acpi/bios.go	83.78% <0.00%> (+83.78%)	⬆️
pkg/acpi/sdt.go	86.66% <0.00%> (+86.66%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[rminnich]

thanks, first time we've seen this, what system was it on? Could you include that in the commit message?

[10000TB]

last element being address is not wrong ?

linux-vdso.so.1 is a virtual shared object, automatically mapped to each process's address space. It is called by libc, not by your program directly (I think?). That is why it does not have a file in typical shared object directory /usr/lib/

[10000TB]

but the print format can be improved, e.g. removing the => in such case.

It should print like linux-vdso.so.1 (0x00007ffe4972d000) ?

Here is an example on my Ubuntu

~$ ldd server
	linux-vdso.so.1 (0x00007ffd4615d000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3516f93000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3516eb4000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f3516eaf000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3516eaa000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f350e41f000)
        ...

[rminnich]

last element being address is not wrong ?

linux-vdso.so.1 is a virtual shared object, automatically mapped to each process's address space.

This is being printed by ld.so, not something we control. It's not wrong, but the whole point of this package is to return a list of files, and we can't return a file in that case, so it needs to be ignored.

What's odd is that the print format has changed. here is my ubuntu:
linux-vdso.so.1 (0x00007ffc3e982000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f88f803a000)

note that if there is no file, there is no =>

whatever system Florian is running on prints a => with an empty file name. That's kind of weird, but we have to accomodate it.

[rminnich]

but the print format can be improved, e.g. removing the => in such case.

It should print like linux-vdso.so.1 (0x00007ffe4972d000) ?

Here is an example on my Ubuntu

~$ ldd server
	linux-vdso.so.1 (0x00007ffd4615d000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3516f93000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3516eb4000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f3516eaf000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3516eaa000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f350e41f000)
        ...

we don't control that print format, right? ldd oln linux does this:
/lib64/ld-linux-x86-64.so.2 --list /bin/date
and we just get the output.

So, sure, that is what your Ubuntu does, but florian's system does something else, and we have to tolerate it.

[10000TB]

]don't know what loader --list prints like previously. But I guess we now know it can change.

but I wonder what it prints like now, with this change ? @florianGla

Based on the comments, it will look like following after removing last line,

linux-vdso.so.1 => linux-vdso.so.1
libc.so.6 => /usr/lib/libc.so.6
libc.so.6 => /usr/lib/libc.so.6 (0x00007ffe4972d000)

first line does not look right, linux-vdso.so.1 => linux-vdso.so.1, kind a self self pointing. That does not look right to me. This library apparently does not have a placement directly in filesystem.

secondly, we have 2 duplicate lines

libc.so.6 => /usr/lib/libc.so.6
libc.so.6 => /usr/lib/libc.so.6 (0x00007ffe4972d000)

they have same linker name and soname (borrowing naming from https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html).

I also wonder what is the output if we run the interpreter directly ? /lib64/ld*.so.* --list <same program>