[Ltrace-devel] Restricting functions printed by ltrace

[Petr Machata]

Reposting with Victor's permission:

Victor Porton <porton at narod.ru> writes:

> 12.08.2014, 11:12, "Petr Machata" <pmachata at redhat.com>:
>> Victor Porton <porton at narod.ru> 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