Adam Malinowski <[email protected]> writes: >> I also see this is broken on master, probably due to my prototype >> library work. Clearly we don't have tests for this. I'll have to fix >> this before 0.8.
A fix for this is on master now, but I've pushed in the middle of something, so even though the test suite passes, for general use it won't even show arguments. The reason is that I split ltrace.conf to libc.so.conf, libacl.so.conf and libm.so.conf, but ltrace only looks for libc.so.6.conf, libacl.so.1.conf, etc. I'll need to change the logic a bit so that it does the useful thing here. > I've also looked at the source for 0.5.3 version and differences are huge. > There was argument type STRING which is missing in current source. > I assume that this is due to completely new approach to prototypes. "string" is still recognized as keyword in config files, but it's not a type anymore--it's something we call "lens". It's a way of looking at an array of bytes. > I needed a tool to trace system calls blocked by seccomp filter of given > process. > It turned out that neither strace nor ltrace has such functionality. > Ltrace seemed to be simpler to modify :) > So I've added cooperation with seccomp to ltrace and enhanced summary a > little. > If you are interested in such changes I will give it to you. > I'm not sure if I did it correctly but it works :) What are the changes that you added to ltrace--can you give a short paragraph with a description? Much depends on whether it can be integrated into ltrace without hacks, and without exposing linux-specific functionality in ltrace core. I'll also have to go and see what seccomp is, I admit ignorance on this subject ;) Thanks, PM _______________________________________________ Ltrace-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
