[英]How to examine vsdo vars?
I would like to inspect the contents of vsyscall_gtod_data (all the time keeping related information that is needed to make clock_gettime() work). 我想检查vsyscall_gtod_data的内容(始终保持使clock_gettime()工作所需的相关信息)。
I'm using gdb to single step through the assembly code of __vdso_clock_gettime() and I'm looking at the following section: 我正在使用gdb一步步完成__vdso_clock_gettime()的汇编代码,然后看以下部分:
0x00007ffff7ffaa71 <clock_gettime+129>: cmp eax,DWORD PTR [rbx]
0x00007ffff7ffaa73 <clock_gettime+131>: je 0x7ffff7ffaa47 <clock_gettime+87>
0x00007ffff7ffaa75 <clock_gettime+133>: jmp 0x7ffff7ffaa56 <clock_gettime+102>
0x00007ffff7ffaa77 <clock_gettime+135>: pause
0x00007ffff7ffaa79 <clock_gettime+137>: mov r12d,DWORD PTR [rbx]
=> 0x00007ffff7ffaa7c <clock_gettime+140>: test r12b,0x1
0x00007ffff7ffaa80 <clock_gettime+144>: jne 0x7ffff7ffaa77 <clock_gettime+135>
0x00007ffff7ffaa82 <clock_gettime+146>: mov eax,DWORD PTR [rip+0xffffffffffffd5fc] # 0x7ffff7ff8084
0x00007ffff7ffaa88 <clock_gettime+152>: mov DWORD PTR [rbp-0x1c],eax
0x00007ffff7ffaa8b <clock_gettime+155>: mov rax,QWORD PTR [rip+0xffffffffffffd61e] # 0x7ffff7ff80b0
0x00007ffff7ffaa92 <clock_gettime+162>: mov QWORD PTR [rsi],rax
0x00007ffff7ffaa95 <clock_gettime+165>: mov edx,DWORD PTR [rip+0xffffffffffffd5e9] # 0x7ffff7ff8084
0x00007ffff7ffaa9b <clock_gettime+171>: mov r10,QWORD PTR [rip+0xffffffffffffd616] # 0x7ffff7ff80b8
0x00007ffff7ffaaa2 <clock_gettime+178>: cmp edx,0x1
0x00007ffff7ffaaa5 <clock_gettime+181>: je 0x7ffff7ffabc0 <clock_gettime+464>
That I believe is the assembly for the following C code (from linux-4.8.0/arch/x86/include/asm/vgtod.h): 我相信是以下C代码的汇编程序(来自linux-4.8.0 / arch / x86 / include / asm / vgtod.h):
static inline unsigned gtod_read_begin(const struct vsyscall_gtod_data *s)
{
unsigned ret;
repeat:
ret = ACCESS_ONCE(s->seq);
if (unlikely(ret & 1)) {
cpu_relax();
goto repeat;
}
smp_rmb();
return ret;
}
(The assembly instruction pause
matches the cpu_relax()
) (汇编指令的
pause
与cpu_relax()
匹配)
As I understand it struct vsyscall_gtod_data *s
is held in rbx
and the address is read in this instruction: 据我了解,
struct vsyscall_gtod_data *s
保存在rbx
并在此指令中读取地址:
mov r12d,DWORD PTR [rbx]
Meaning that the debugged program can read this address, but when I try to examine it in gdb I get an error: 这意味着调试后的程序可以读取该地址,但是当我尝试在gdb中检查它时,出现错误:
(gdb) x $rbx
0x7ffff7ff8080: Cannot access memory at address 0x7ffff7ff8080
(gdb)
Any ideas of what's going on and how to examine that memory? 关于发生了什么以及如何检查该内存的任何想法?
I think you are trying to access a memory location that can be accessed only if you have "privilege level" 0 (OS level). 我认为您正在尝试访问仅当您具有“特权级别” 0(操作系统级别)时才能访问的内存位置。 Don't trust me on the name, I read it a couple of days ago on the Intel manual so I might get the jargon wrong, the concept should be right though.
不要相信我的名字,几天前我在Intel手册上读了它,所以我可能会误解这个行话,但是这个概念应该是正确的。
I am not 100% sure that it would be enough to sudo, but trying will not hurt. 我不是100%肯定sudo就足够了,但是尝试不会有任何伤害。 I know some instruction counting registers have similar issues and they can be accessed from userspace if you sudo.
我知道一些指令计数寄存器也有类似的问题,如果您使用sudo,可以从用户空间对其进行访问。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.