Petr Machata <[email protected]> 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 _______________________________________________ Ltrace-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
