[Ltrace-devel] Per-library config files

[Petr Machata]

Hi there,

one thing that I have wanted to do for a long time is allowing libraries
to distribute ltrace config files.  This came in as a RFE to Red Hat
bugzilla years ago, when I wasn't involved with ltrace as much, and it's
been lying at the back of my mind since then.  So about a week ago I
created a branch pmachata/conf, where this feature is being worked on.

The motivation is twofold.  First, stuffing everything in ltrace.conf is
impractical and there's no way to resolve namespace collisions (though
the latter could be worked around by same sort of soname tagging in
ltrace.conf itself).  Second, it's essentially impossible for arbitrary
upstream to decide to support ltrace, or for ltrace to describe more
than a handful libraries (without horribly bloating the file).

The code on the branch solves this by having a config directory, where
one conf file per DSO is stored.  The following directories are checked:

- $XDG_CONFIG_HOME/ltrace, $HOME/.ltrace
- $XDG_CONFIG_DIRS (which is a list in fact) and @sysconfdir@/ltrace

There is actually a per-OS hook, so various OS's can provide their idea
of where the config files should be.

For each mapped-in library, the config directories are looked into for a
config file named $SONAME.conf.  (E.g. libc.so.6.conf, libdl.so.2.conf.)
When one is found, it's parsed into a prototype library ("protolib"),
and that's where prototypes are looked up.

When a breakpoint is hit, only the relevant prototype libraries are then
consulted.  For static symbols (-x) this is the library where the symbol
is defined.  For PLT symbols (-e), all libraries of given process.

There's provision for one protolib to import another.  If the name is
not found in the prototype library itself, its imports are consulted.
I envision having a config-file artifact for this ("import xyz;"), but
currently there is none.  This feature is however used extensively
internally.

One use is legacy typedefs ("addr", "file"), which are a protolib
implicitly imported to all other protolibs.  Another use is backward
compatible support for ltrace.conf, $HOME/.ltrace.conf, and -F.  These
are all implicitly imported to any loaded $SONAME.conf file, in case
they contain any customization not covered by $SONAME.conf.

-F newly accepts a colon-separated list of paths and file names.  Paths
are looked into for config files.  File names become implicit imports.

The import feature also ties closely into another thing that I wanted to
fix for some time.  Ltrace internally works with types like "long",
"int", "char".  These need to be translated to their actual width.  For
structure layout, parameter passing convention, etc., backends need to
translate these symbolic names back to their actual width.  But ABI
documentation typically describes things in terms of fixed-width types.
It would be more natural to use fixed widths internally, and ltrace
should support types like uint8_t, int32_t anyway.

Thus ltrace should ditch ARGTYPE_INT and others, and instead use
ARGTYPE_{,U}INT{8,16,32,64}.  Backends would then provide an ABI
protolib, which would contain typedefs for int, long, etc., and also
e.g. size_t, uintptr_t and others.  char would likely become either of
string({,u}int8_t).  This module would be an implicit import of any
prototype library, which would naturally use int's and long's as
appropriate.

I'm not about to start hacking on this anytime soon, but that's where
I would like ltrace to be at some point in future.

Thanks,
PM