Unable to access contents of a [vvar] memory region in GDB?

Question

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:

• Implementing virtual system calls - an old (October 2014) and most likely outdated LWN article article mentioning the [vvar] section. Didn't understand half of it.
• vvar, gup && coredump - a kernel mailing list thread (March 2015) about what seems to be the same issue. Didn't understand neither.

I'd appreciate it if anyone could explain this to me in simpler terms.

Answer 1

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).