[Ltrace-devel] Getting prototypes from debug information

Dima Kogan lists at dima.secretsauce.net
Sun Apr 13 21:45:43 UTC 2014


Petr Machata <pmachata at redhat.com> writes:

> Dima Kogan <lists at dima.secretsauce.net> writes:
>
>> 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.

OK. I have a version that works for some value of "works". The tree is
here:

 https://github.com/dkogan/ltrace

There are 3 patches, 2 to adjust some related ltrace behavior, and one
big patch adding the feature being discussed. Of the non-feature
patches, one should be merged, and the other is temporary, and should be
addressed in a better way; it's pretty clear when you look at it.

The feature works. It parses out the DWARF info into ltrace structures,
which enables tracing without conf files. I'm certain I don't support
all the dwarf stuff that could exist, but it should be enough for now,
probably. A clear piece that is missing is unions, because I don't
believe ltrace itself handles those yet. Also bit-fields and anything
else that I forgot and haven't run into yet myself. Enums DO appear in
the dwarf data, and I do handle them.

Like you said, there are things that could be described in the conf
files that dwarf lacks, so a hybrid would be great. For instance the
conf could describe the layout of some structure, and the prototypes
that use it could be pulled from the dwarf. Both sources of data are
read right now, but I don't think the intelligent merging works yet.

Another issue with the current code is that I'm not yet completely clear
on ltrace's memory management, so I shamelessly leak all my
heap-allocated memory.

I don't want to clean this up further without some input from the
maintainers. Is this approach sound? Any glaring issues I'm not seeing?

dima



More information about the Ltrace-devel mailing list