printing the instruction pointer under x86-64
roland at redhat.com
Thu Apr 23 08:39:56 UTC 2009
> I have a question regarding the ability of strace to print the
> instruction pointer where the syscall takes place. I'm trying to use
> this feature to trace a 32-bit process running on a amd64 gentoo
> system. Unfortunately, the eip values returned by strace don't make
> much sense:
I'm sorry you're confused by them, but I think they are probably correct.
> [ f7fc6430] lstat64("/etc/opt/cisco-vpnclient",
This is the address in your vDSO. Look at e.g. /proc/self/maps (if using a
32-bit "cat", I guess--use /proc/<pid>/maps) for the "[vdso]" line.
If you use gdb on your program, you will see it describe this PC like this:
0xf7fc6430 <__kernel_vsyscall+16>: pop %ebp
That's the PC. It really is. It's just not helpful to you.
But that's the way it goes. Sorry.
The vDSO is a shared library provided by the kernel on some architectures.
In x86-32 processes, the C library calls into this library to make a system
call (__kernel_vsyscall). So it's the caller of that frame that is what is
really interesting. Actually usually that caller is in libc and that is
boring too. You need its caller, or the one before that, to actually get
to your program's own code. i.e., you want a full stack backtrace. In
modern systems, that requires interpreting (and having) unwind information
(which you do have in the vDSO). strace is just prepared to do that.
More information about the Strace-devel