Re: ldd output for sysinfo DSO

[Daniel Jacobowitz <drow at mvista dot com>]

On Tue, Sep 30, 2003 at 01:45:17PM -0700, Roland McGrath wrote:
> > The leading tab is because of the sysinfo DSO.  Its address is in kernel
> > space, so writev() stops when it sees the pointer, and nothing gets written.
> 
> It still seems to me that the proper solution to this issue is for the
> kernel to treat user addresses consistently.  That is, what you can access
> from userland you can access via system calls that use user addresses.
> 
> > The other sensible alternative is to skip it entirely.
> 
> This might be wise for unrelated reasons.  I don't know what all groks ldd
> output, but there may well be scripts around that assume that the rhs names
> a file that can (and should) be found.  linux-gate.so.1 refers to no file.

I see that Roland's changed it not to set l_libname.  Now we get:

drow@nevyn:/big/fsf/glibc% ./elf/ld.so --list --library-path .:rt:linuxthreads:/lib /bin/ls
        linux-gate.so.1 =>  (0xffffe000)
        librt.so.1 => rt/librt.so.1 (0x40001000)
        libacl.so.1 => /lib/libacl.so.1 (0x40014000)
        libc.so.6 => ./libc.so.6 (0x4001b000)
        libpthread.so.0 => linuxthreads/libpthread.so.0 (0x4014a000)
        /lib/ld-linux.so.2 => ./elf/ld.so (0x80000000)
        libattr.so.1 => /lib/libattr.so.1 (0x4019c000)

Is that really an improvement?  It'll sure confuse a lot of scripts
that parse ldd output.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer