PATCH: ldd and LD_DEBUG completions

PATCH: ldd and LD_DEBUG completions

[Oliver Kiddle]

Attached are completions for ldd and the LD_DEBUG environment variable.
The use of the Unix/Type directory for the latter is perhaps
questionable but is probably the best choice. These are based on Linux
and Solaris. I would have checked BSD but the sourceforge compile farm
has gone.

The zsh libraries are not especially cleanly linked by the way. Run ldd
-ur (preferably on Solaris) on them to see what I mean.

Oliver

Index: Completion/Unix/Command/_ldd
===================================================================
RCS file: Completion/Unix/Command/_ldd
diff -N Completion/Unix/Command/_ldd
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ Completion/Unix/Command/_ldd	28 Jun 2007 16:11:00 -0000
@@ -0,0 +1,32 @@
+#compdef ldd
+
+if _pick_variant gnu=GNU solaris --version; then
+  args=(
+    '(- *)--version[display version information]'
+    '(- *)--help[display help information]'
+    '(-v --verbose)'{-v,--verbose}'[include symbol versioning information]'
+    '(-d --data-relocs)'{-d,--data-relocs}'[perform data relocations and report missing objects]'
+    '(-f --function-relocs)'{-f,--function-relocs}'[perform data/function relocations and report missing objects]'
+    '(-u --unused)'{-u,--unused}'[display any unused objects]'
+  )
+else
+  args=(
+    -s
+    '(-r)-d[check immediate references]'
+    '(-d)-r[check immediate and lazy references]'
+    '-u[display any unused objects]'
+    '-U[display any unreferenced, or unused dependencies]'
+    '-e[set specified environment variable]:environment variable:(LD_PRELOAD LD_LIBRARY_PATH LD_RUN_PATH LD_DEBUG LD_DEBUG_OUTPUT LD_NOCONFIG LD_NOAUXFLTR)'
+    '-f[check for insecure executable]'
+    '-i[display order of execution of initialization sections]'
+    '-L[enable lazy loading]'
+    '-l[force immediate processing of any filters]'
+    '-s[display search path used]'
+    '-v[displays all dependency relationships]'
+  )
+fi
+
+_arguments $args \
+  '*: : _alternative
+    "executables:executable:_files -g \^\*.so\(\*\)"
+      "shared-objects:shared object:_files -g \*.so"'
Index: Completion/Unix/Type/_ld_debug
===================================================================
RCS file: Completion/Unix/Type/_ld_debug
diff -N Completion/Unix/Type/_ld_debug
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ Completion/Unix/Type/_ld_debug	28 Jun 2007 16:11:00 -0000
@@ -0,0 +1,39 @@
+#compdef -value-,LD_DEBUG,-default-
+
+local vals
+
+vals=(
+  'libs[display library search paths]'
+  'files[show processing of files and libraries]'
+  'bindings[display symbol binding]'
+  'reloc[display relocation processing]'
+  'symbols[display symbol table processing]'
+  'unused[show unused files]'
+  'versions[show version processing]'
+  'help[display help message]'
+)
+
+case $OSTYPE in
+  solaris*)
+    vals+=(
+      'basic[provide basic trace information/warnings]'
+      'cap[display hardware/software capability processing]'
+      'detail[provide more info in conjunction with other options]'
+      'demangle[display C++ symbol names in their demangled form]'
+      'init[display init and fini processing]'
+      'long[display long object names without truncation]'
+      'move[display move section processing]'
+      'segments[display available output segments and address/offset processing]'
+      'strtab[display information about string table compression]'
+      'tls[display TLS processing info]'
+    )
+  ;;
+  linux*)
+    vals+=(
+      'all[combine all options]'
+      'statistics[display relocation statistics]'
+    )
+  ;;
+esac
+_values -s , capability $vals
+  

Re: PATCH: ldd and LD_DEBUG completions

[Peter Stephenson]

Oliver Kiddle wrote:
> The zsh libraries are not especially cleanly linked by the way. Run ldd
> -ur (preferably on Solaris) on them to see what I mean.

I'm getting this:

        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libcurses.so.1 =>        /usr/lib/libcurses.so.1
        libm.so.1 =>     /usr/lib/libm.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        /usr/platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1

   unused object=/usr/lib/libsocket.so.1

Mostly that doesn't look unreasonable.

Are you referring to the fact that all system libraries needed in zsh
and its modules are linked into the main shell and all modules?  That's
a fairly cosmetic problem requiring a rewrite of the build system that's
likely to be 1,798,109,308th in my global list of things to worry about.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php

To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview

Re: PATCH: ldd and LD_DEBUG completions

[Danek Duvall]

On Thu, Jun 28, 2007 at 05:12:46PM +0100, Oliver Kiddle wrote:

> The zsh libraries are not especially cleanly linked by the way. Run ldd
> -ur (preferably on Solaris) on them to see what I mean.

One thing I plan to do next time I have time to poke at zsh is to build it
with "-z ignore" in LD_OPTIONS, which I believe ought to eliminate the
extraneous libraries in each ELF object.  If you build your own zsh on
Solaris, give this a shot, and see if it actually makes a difference.

Danek

Re: PATCH: ldd and LD_DEBUG completions

[Peter Stephenson]

Danek Duvall wrote:
> On Thu, Jun 28, 2007 at 05:12:46PM +0100, Oliver Kiddle wrote:
> 
> > The zsh libraries are not especially cleanly linked by the way. Run ldd
> > -ur (preferably on Solaris) on them to see what I mean.
> 
> One thing I plan to do next time I have time to poke at zsh is to build it
> with "-z ignore" in LD_OPTIONS, which I believe ought to eliminate the
> extraneous libraries in each ELF object.  If you build your own zsh on
> Solaris, give this a shot, and see if it actually makes a difference.

Yes, that does seem to work... omitting symbols from the main zsh binary
not found in Modules/socket.so, I now get

18:10% ldd -ur zsh 
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libcurses.so.1 =>        /usr/lib/libcurses.so.1
        libm.so.1 =>     /usr/lib/libm.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        /usr/platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1
18:10% ldd -ur Modules/socket.so
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        /usr/platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1

so libsocket has correctly only linked against the module that needs it,
and libcurses is missing from the socket library.  The shell runs and
the module loads OK.

This looks like it's worth hacking into configure somehow.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php

To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview

Re: PATCH: ldd and LD_DEBUG completions

[Phil Pennock]

On 2007-06-28 at 17:21 +0100, Peter Stephenson wrote:
> Are you referring to the fact that all system libraries needed in zsh
> and its modules are linked into the main shell and all modules?  That's
> a fairly cosmetic problem requiring a rewrite of the build system that's
> likely to be 1,798,109,308th in my global list of things to worry about.

It affected me when I was creating my ruby plugin (which I haven't
worked on in weeks); I hacked around the configure/make/sh-scripts
system to let the linking be on individual modules, with better
independent configuration.  I don't remember where things _really_
broke, might have been the libcrypt pull-in.  (Of course, I later
remembered which language it was I'd been trying to remember, designed
for embedding and the one I _wanted_ to test with; lua).

I need to research what's available pre-packaged as autoconf stuff to
detect systems where everything needs to be linked into the main binary,
so that I can merge this in without killing support for some of zsh's
platforms.  I'm planning to schedule time this weekend to look at this.

Anything I offer will only have been tested on FreeBSD6/amd64 and MacOS
10.4.10/x86, so there's likely to be breakage, hence not having offered
anything before now.

Does the output below look reasonable and desirable to people?

% ldd -a bin/zsh
bin/zsh:
	libzsh-4.3.4-dev-0.so => /home/pdp/dbg/lib/zsh/libzsh-4.3.4-dev-0.so (0x800631000)
	libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x8007f6000)
	libncurses.so.6 => /lib/libncurses.so.6 (0x8009e7000)
	libm.so.4 => /lib/libm.so.4 (0x800b40000)
	libc.so.6 => /lib/libc.so.6 (0x800c5c000)
/home/pdp/dbg/lib/zsh/libzsh-4.3.4-dev-0.so:
	libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x8007f6000)
	libncurses.so.6 => /lib/libncurses.so.6 (0x8009e7000)
	libm.so.4 => /lib/libm.so.4 (0x800b40000)
	libc.so.6 => /lib/libc.so.6 (0x800c5c000)
% ldd lib/zsh/4.3.4-dev-0/zsh/pcre.so 
lib/zsh/4.3.4-dev-0/zsh/pcre.so:
	libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x80093b000)
	libncurses.so.5.6 => not found (0x0)
	libm.so.4 => /lib/libm.so.4 (0x800b2c000)
	libc.so.6 => /lib/libc.so.6 (0x800632000)
	libpcre.so.0 => /usr/local/lib/libpcre.so.0 (0x800c48000)
% ldd -a lib/zsh/4.3.4-dev-0/zsh/ruby.so
lib/zsh/4.3.4-dev-0/zsh/ruby.so:
	libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x80093c000)
	libncurses.so.5.6 => not found (0x0)
	libm.so.4 => /lib/libm.so.4 (0x800b2d000)
	libc.so.6 => /lib/libc.so.6 (0x800632000)
	libruby18.so.18 => /usr/local/lib/libruby18.so.18 (0x800c49000)
/usr/local/lib/libruby18.so.18:
	libcrypt.so.3 => /lib/libcrypt.so.3 (0x800e32000)
	libm.so.4 => /lib/libm.so.4 (0x800b2d000)

Re: PATCH: ldd and LD_DEBUG completions

[Peter Stephenson]

Phil Pennock wrote:
> Does the output below look reasonable and desirable to people?

The libraries there look they're used by some part of the shell,
but probably not every library is being used by every part that's
linked against it.  For example, if there's a libzsh containing most of
the code, I would expect the main zsh executable to require virtually no
libraries beyond libc.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php

To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview

Re: PATCH: ldd and LD_DEBUG completions

[Oliver Kiddle]

Peter wrote:
> Oliver Kiddle wrote:
> > The zsh libraries are not especially cleanly linked by the way. Run ldd
> > -ur (preferably on Solaris) on them to see what I mean.
> 
> I'm getting this:
>    unused object=/usr/lib/libsocket.so.1
> Mostly that doesn't look unreasonable.

Not unreasonable but you get curses in there too for a lot of libraries.
(I wonder whether curses dependent things could be moved to zle.so so
that a non-interactive zsh didn't need it).

> That's a fairly cosmetic problem requiring a rewrite of the build system that's

It's not entirely cosmetic. Removing unused dependencies can reduce
startup times. Optimising this made a very noticeably difference to some
other software a colleague of mine was working on (though admittedly
that was pulling in a lot more stuff from libraries).

And while I agree that rewriting the build system for this issue would
be excessive, it is closely related to the issue of modules having extra
dependencies.  Didn't Clint put in some hack so that only the cap module
depends on libcap.so.

As pointed out by Danek, using -z ignore for compiler's that support it
could be an easy fix. At the very least, Debian etc packages could do
this (Hello Clint). In some cases Sun's -z lazyload would also
be useful (e.g. iconv). 

Note: ldd -u -r also lists a lot of "symbol not found" errors. I think
these may be the symbols from the main zsh binary (or libzsh) so they
aren't an issue. With most software, they indicate that your library
needs to be linked against other libraries (the same information comes
from the compile option -z defs).

Oliver

Re: PATCH: ldd and LD_DEBUG completions

[Clint Adams]

On Fri, Jun 29, 2007 at 11:42:41AM +0100, Oliver Kiddle wrote:
> And while I agree that rewriting the build system for this issue would
> be excessive, it is closely related to the issue of modules having extra
> dependencies.  Didn't Clint put in some hack so that only the cap module
> depends on libcap.so.

cap and pcre.  It's ugly and fragile and probably unportable, so I never
committed it, but it's used to build the Debian package.

> As pointed out by Danek, using -z ignore for compiler's that support it
> could be an easy fix. At the very least, Debian etc packages could do
> this (Hello Clint). In some cases Sun's -z lazyload would also
> be useful (e.g. iconv). 

Get that feature into GNU binutils and we have a deal.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=430989

Re: PATCH: ldd and LD_DEBUG completions

[Oliver Kiddle]

Clint wrote:
> Get that feature into GNU binutils and we have a deal.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=430989

Sorry, I thought it was there but it turns out that you can pass
-z anything_you_like and it'll silently ignore it.

Oliver

Re: PATCH: ldd and LD_DEBUG completions

[Bart Schaefer]

On Jun 29,  8:11am, Clint Adams wrote:
}
} Get that feature into GNU binutils and we have a deal.
} http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=430989

The zsh build system will still have to know how to deal with the lack
of that option ... and apparently also know how to deal with having a
compiler that appears to implement it but ignores it.

Re: PATCH: ldd and LD_DEBUG completions

[Oliver Kiddle]

Bart wrote:
> On Jun 29,  8:11am, Clint Adams wrote:
> } Get that feature into GNU binutils and we have a deal.
> 
> The zsh build system will still have to know how to deal with the lack
> of that option ... and apparently also know how to deal with having a
> compiler that appears to implement it but ignores it.
 
Not for a Debian package specific change it wouldn't.

-z ignore appears to be a linker option as opposed to being a compiler
option. I'm not sure how to detect the Sun linker given that I think
you can have gcc with the Sun linker. One option would be:
  compile a dummy .so
  compile a dummy binary linked against the .so explicitly with -z ignore
  rm the .so
  run the binary and see if you get an ld error.

It's actually now possible to get Sun studio for Linux. I just tried
compiling zsh with it. The only problem is that the compiler doesn't
handle the -rdynamic option. It is still using the GNU linker and
passing -export-dynamic instead of -rdynamic seems to do the trick.
That's line 2328 of configure.ac. What's the best way to handle that
from configure. We could check $ac_compiler_gnu but there's also the
Intel compiler to consider. Should we add a check for the Sun compiler
instead?

Oliver