[Ltrace-devel] Config files

[Petr Machata]

Dima Kogan <lists at dima.secretsauce.net> writes:

> Hi all.
>
> In putting together the test suite, I hit a few issues with conf files.
> Those are all described together in this email.
>
> When running the test suite, I would think we want to be testing the
> build of ltrace that appears in the checked-out source tree, and that it
> should be independent of the user's local configuration or the overall
> system. Thus I would expect
>
> - ~/.ltrace to not be read
> - /etc/ltrace to not be read either
> - etc/ in the source tree to be read

Agreed.  I never got around to implementing this, but it's desirable.
There's a test case that fails if you run ltrace built with
pkgdatadir=/etc.  I know to look for these, but others naturally don't,
and it causes some trouble now and then.

My thinking was to introduce a --sysroot, akin to what gcc and ld have.
For testing, this could be set to source directory, or whatever.

I don't know how to cleanly disable reading of user config files.
Environment variable?  Another flag?  Some -F mojo?

> currently I'm observing that
>
> - ~/.ltrace is read
> - /etc/ltrace is not read

This might be because /usr/local/etc/ltrace is attempted and not found.

> - etc/ in the source tree is not read
>
> This sounds wrong. Complaints against patching it in this way?

Depends on how exactly you want to have it patched ;) The sysroot
approach is somewhat appealing to me, but only solves half of the
problem.  Maybe you have something better in mind.

> The DWARF parser interprets every structure as deeply as possible. This
> is often undesirable. For instance when tracing something like ftell(),
> ltrace wants to print all components of its FILE* argument. On my libc,
> this eventually contains a void value, and ltrace does an assert(0)
> trying to print it. We want to ship something like

I wonder if that's a bug in ltrace.  Either claiming that a value is of
type void (what does that mean, exactly?), or else, if there are
legitimate reasons (void pointers and return types aside), that it
asserts on them.

>  typedef FILE = addr;
>
> in our config files. We DO have this in libc.so.conf, but this has 2
> problems:
>
> 1. this file isn't read by the test suite, as mentioned above
>
> 2. On Debian, the DWARF data has ftell(_IO_FILE*), not ftell(FILE*). It
> also has typedef FILE = _IO_FILE. Thus the typedef in the conf file has
> no effect. We can add to the conf file
>
>  typedef _IO_FILE = FILE

Just to be clear, the reason for this typedef is backward compatibility.
ltrace used to recognize FILE as a bulit-in type, but it never did
anything useful with it.  When I rewrote type handling, I decided to
drop it and just exposed it as a typedef of addr.

> but this is an implementation detail of glibc, so this is unideal. We
> can also do something complicated like realizing that FILE is defined in
> the conf file, and then treat the typedef in the DWARF backwards.
> Suggestions?

What do you mean, backwards?

The useful way of handling FILE would probably be to pry interesting
data from it and display that.  Like, file descriptor if any, stream
position, that sort of thing.  This sort of thing is already hard to
write with the current, um, "scripting" language in ltrace, and it's
pretty much impossible unless we can distinguish one glibc from
another.

Thanks,
PM