This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Question regarding userspace tracing memcpy in glibc
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: Holger Freyther <holger at freyther dot de>
- Cc: systemtap at sources dot redhat dot com
- Date: Fri, 26 Nov 2010 16:58:03 -0500
- Subject: Re: Question regarding userspace tracing memcpy in glibc
- References: <loom.20101126T174831-857@post.gmane.org>
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