This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Question regarding userspace tracing memcpy in glibc


holger wrote:

> [...]
> I have an application that is spending some time copying structs with
> memcpy. I wanted to use systemtap to figure out who is calling memcpy,
> [...]
> $ stap -e 'probe process("/lib/libc.so.6").function("memcpy") {printf();...}'
> [...]
> $ stap -e 'probe process("/lib/libc.so.6").function("__memcpy_ssse3")..
> [...]

Right.  These are assembly language functions, with no dwarf data,
just a symbol table entry.  We ought to be able to attach to them
anyway though, equivalently to ...

> the next idea would be I find the address of the memcpy with GDB and
> then try to use this with .statement(address_of_memcpy) but that
> does not work either. [...]

(As in, on my f13 x86-64 box:

% nm /lib64/libc-2.12.1.so| grep memcpy
00000032a2c83c60 t __GI_memcpy
00000032a2c83c50 T __memcpy_chk
00000032a2c8b580 t __wmemcpy
00000032a2cf9b00 T __wmemcpy_chk
00000032a2c83c60 T memcpy
00000032a2c9f8a0 t memcpy_uppcase
00000032a2c8b580 W wmemcpy
% stap -e 'probe
     process("/lib64/libc-2.12.1.so").statement(0x00000032a2c83c60),
     process("/lib64/libc-2.12.1.so").statement(0x00000032a2c83c50) {}' \
  -tv -c 'ls'
[errors]

This should actually work too.  This sounds like a special case of
our <http://sourceware.org/PR10208>.

- FChE


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]