[Ltrace-devel] Getting prototypes from debug information

Petr Machata pmachata at redhat.com
Mon Apr 7 23:42:19 UTC 2014


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

> Currently it appears that all function prototypes are read from the
> .conf files. Can these be read in from the debug information instead?

They sure can.

> ltrace already uses libdw, so I'm assuming either this is not possible,
> or it's on somebody's short-term todo list. Any thoughts about it?

It uses it optionally for unwinding, yes.  It could use it optionally
for prototype retrieval as well.  This idea has crossed my mind in the
past, and I wouldn't oppose patches that extend ltrace into accepting
debuginfo if available.

The downside of using Dwarf is that you don't have all the information
that you have with config files--e.g. ltrace wouldn't know that some
integer somewhere is actually an enum, wouldn't know which fields are
used as flags (for which we currently lack support, but is generally
doable), etc.  I would also like to make it possible to annotate
functions as potential errno setters--that would be lost with Dwarf as
well.  (But that's not written either, and errno is thread-local, which
makes extracting it... interesting.)

But realistically, we can cover with config files maybe a dozen coremost
OS libraries and language runtimes, maybe X, a couple graphical
toolkits, and that's about it--and I'm being nebulously optimistic.  For
the remaining 99.99% libraries, Dwarf would be a very viable solution.

A mixed approach, where ltrace takes available prototypes from the
config files, and the rest from debuginfo, would probably be the best.

Oh, but note that even though Dwarf contains location expressions for
arguments, those tend to be wrong for function entry points (certainly
small structs on x86_64 unless recent GCC's fixed it, and I'm pretty
sure I've seen more cases like this; HFA aggregates on machines that
pass them in registers are automatically suspicious).  The Dwarf backend
should really extract the prototype and translate it to ltrace
type_info's, and let the built-in parameter-passing backend do the work.

This would be an interesting project.  Feel free to tackle it.

Thanks,
PM



More information about the Ltrace-devel mailing list