[Ltrace-devel] Getting prototypes from debug information

[Dima Kogan]

Petr Machata <pmachata at redhat.com> writes:

> The integration with conf-based protolibs is kinda tricky.  What we
> currently do for somelib.so.1.2.3 is look for somelib.so.1.2.3.conf,
> then somelib.so.1.2.conf, then somelib.so.1.conf, and then
> somelib.so.conf.  I think it's only there that we should fall back on
> dwarf

Hi Petr. Thanks for the detailed review. I'll address your comments in a
bit, but I still have some high-level questions.

I think it would be most useful to read in a combination of DWARF and
.conf files, instead of just one of the two. For instance, the code I
have can parse FILE structures, so when ltrace decodes an fprintf()
call, you get the full dissection of the FILE argument. This is less
than useful. In cases like this I can imagine a .conf file can define a
lens that says how to display a FILE, and the DWARF parsing can then be
used to pull out the function prototype. I'm thinking that the .conf
files should be parsed first, and those should take precedence over any
DWARF data. Any thoughts on this? Implementation suggestions?

Currently I parse the DWARF from all our DSOs, and there's a lot of
overlapping DWARF data there. It's all imported into separate plibs.
This sounds like it's probably fine (although inefficient). Thoughts?

The code I have tries to consult the ltrace filters to parse the DWARF
only from functions and libraries the user asked about. I can't tell if
this works or not. The ltrace documentation is very unclear on the
difference between -e, -x and -l, so I don't yet know if that code is
working correctly. Does it look like it's correct? I'm talking about the
filter_matches_symbol() and filter_matches_library() calls.

I think that's it. Thanks again

dima