Joe Damato <[email protected]> writes: > On Tue, Mar 19, 2013 at 6:25 PM, Petr Machata <[email protected]> wrote: >> Joe Damato <[email protected]> writes: >> >>> joe@ubuntu:~/code/ltrace$ /tmp/test/usr/local/bin/ltrace -e* -p 2821 >>> libm.so.6->(0x7fff07366f90, 0x7fff07366f90, 0, -1) >>> = 0x7f0384fe06a0 >>> libdl.so.2->__cxa_finalize(0x7f038582f078, 0, 0xffffffff, 0x7f038582ed50) >>> = 0x7f0385627350 >>> libm.so.6->(0x7f038526c0c0, 0, 0, 3) >>> = 0x7f0385627350 >>> +++ exited (status 0) +++ >> > Appears that my libm does go through the PLT for 2 things: > > 0000000000025ca0 <acos>: > [...] > 25cb6: e9 f5 f7 fd ff jmpq 54b0 <*ABS*+0x10590@plt> > [...] > 25cd7: e9 64 fc fd ff jmpq 5940 <*ABS*+0x1fc30@plt+0x3e0>
In that case we are missing one PLT call in your output. Tracing both -x acos@libm\* and -e\* would help us indicate what the exact order of operations is. Would you mind sending me your libm.so binary privately? Chances are I'll be able co reproduce the problem with it, distill a test case, etc. Thanks, PM _______________________________________________ Ltrace-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
