Reposting with Victor's permission: Victor Porton <[email protected]> writes:
> 12.08.2014, 11:12, "Petr Machata" <[email protected]>: >> Victor Porton <[email protected]> writes: >>> I use >>> >>> ltrace -n4 -A10 -llibraptor2.so.0 ./obj/test/debug/run_all_tests 2>&1| >>> egrep ^[a-z] >>> >>> to output only these calls which happen from my program >>> run_all_tests not other functions of libraptor2. >>> >>> This use of grep is silly. There should be a command line option of >>> ltrace which would limit only to functions called from the user >>> supplied program (not from other parts of the traced library), or more >>> generally limit to N levels of indirection (by indirection I mean the >>> same thing which directs indentation when -n4 or a similar option is >>> supplied). >> >> I agree, this sort of filtering shoud be doable on selector level. >> I don't think we cover this right now. -e allows this sort of >> fine-grained selection, but you can't say >> -e <symbols that come from libfoo.so>@myprogram. My current thinking is that we could extend -e to something like [soname_pattern:][symbol_pattern][@soname_pattern] (i.e. add the initial optional soname selector). -l libfoo.so would become syntax sugar for -e libfoo.so:*@*. This would require merging the logic for our PLT handling and export handling. Symbols that match the *@* part, but not the *: part would be made latent. Later if a library is mapped that matches the *:, those symbols would be activated. (Actually the logic would be a bit more complex. When a library is mapped that matches the *: part of some rule, we look up libraries that match the *@ part of the same rule, and in those, enable the symbols that match the * part of that rule. We can't just whole-sale enable everything latent that the newly-mapped library brings in, as that would break cases like -e libfoo.so:x*@A -e libbar.so:y*@A. If libfoo has symbols x1 and y1, and libbar has x2 and y2, and all of these are called from A, we only wish to enable x1 when libfoo is mapped, and never x2 when libbar is mapped; and vice versa--only enable y2 when libbar is mapped, and never y1 when libfoo is mapped.) Filtering based on -n distance is another feature request, and I don't really have any thoughts on this. Tell me what you think. Thanks, PM _______________________________________________ Ltrace-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
