For instance: ftrace -sym '*cairo*' /usr/bin/gtk-demo or ftrace -sym @libcairo.so /usr/bin/gtk-demo or?
This would work if cairo is not stripped: ftrace -sym='@libcairo*' otherwise you can only trace dynamic symbols: ftrace -dyn='@libcairo*' Separate debuginfo doesn't help, ftrace doesn't have the necessary functionality implemented. I guess this will be available for free when I teach ftrace to set breakpoint on arbitrary location (bug 5696), right?
Ok, I'm starting to see the differences between -sym and -dyn. -sym is for an arbitrary symbol? -dyn is all entry points part of the bug here is likely documentation helping to clarify this. I also wonder if a -library <blah> would be more directly understandable? I'm not sure that typical uses want to learn the differences between plt and dynamic tables :-)
Once 5696 is resolved, we can consolidate the tracing interface. I agree and myself feel it's due. Right now the behavior is: -sym: look for the symbols inside symbol table -dyn: look for the symbols inside dynamic symbol table (trace exported symbols) -plt: place the breakpoint on PLT entry (trace "imported" symbols) Re the documentation, I try to keep ftrace man page up to date with all the necessary explanations. I just checked that it's included in the latest greatest frysk Fedora package.
The commandline to use is: ftrace -sym=cairo_* -- /usr/bin/gtk-demo or ftrace -sym=plt:cairo_* -- /usr/bin/gtk-demo depending on whether you are after where the calls end (the first case) or where the calls originate (the second case). Calls that end in libcairo can be traced like this: ftrace -sym=#libcairo*#* -- /usr/bin/gtk-demo (which can be combined with plt: again) This didn't get it into 0.4, but is in git, which means it should be in 0.5 at the end of June or early July.