I'm live-debugging a process in GDB under Linux and I find it impossible to read the contents of the memory region defined in /proc/${PID}/maps
as:
3aaef123000-3aaef125000 r--p 00000000 00:00 0 [vvar]
Clearly, the r
flag in r--p
shows that it is readable, but GDB always tells me it is unable to access the contents of that memory region, e.g.:
warning: Unable to access <count> bytes of target memory at <address>, halting search.
What exactly is a [vvar]
memory region? Why can't I read its contents from GDB?
EDIT: Off-site resources which might help answer the question:
[vvar]
section. Didn't understand half of it.I'd appreciate it if anyone could explain this to me in simpler terms.
What exactly is a [vvar] memory region?
Explanation here.
Why can't I read its contents from GDB?
That sounds like a bug in the kernel ptrace
implementation: if the process can read the data, so should the process's tracer (GDB here).
But it doesn't always work this way. For example, GDB can examine stack guard pages, which the process itself can't access (i.e. this is a kernel bug in opposite direction).
Update:
I'd appreciate it if anyone could explain this to me in simpler terms
There is really not much to it: in order to implement certain simple system calls (such as gettimeofday
) faster, it is convenient for the kernel to make some kernel data visible to user-level processes, and that is exactly what it does: a page (or two) of kernel data is "magically" mapped into every process at some address, and a method is provided for the user process to find the virtual address where that page appears.
The rest is mostly irrelevant implementation details.
You may also find this explanation of the VDSO page helpful (it's about code rather than data, but the idea is pretty much the same).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With