Re: [PATCH] Improve corefile generation by using /proc/PID/coredump_filter (PR corefile/16902)

[Oleg Nesterov <oleg@redhat.com>]

On 03/12, Pedro Alves wrote:
>
> On 03/12/2015 03:00 PM, Oleg Nesterov wrote:
>
> > However. If (for any reason) you decide to dump this region, gdb can
> > look into /proc/self/maps, find its own "vvar" mapping, and simply read
> > this memory. Unlike "vdso", "vvar" has the same content for every process.
>
> Actually it can't: GDB may well be dumping the memory of
> a process running on another machine (through gdbserver).

Yes, thanks for correcting me...

I do not know if gdb can ask gdbserver to read its own memory, but even if
it can this doesn't look like a nice solution.

Just curious... I know that gdb can execute the code on behalf of the traced
process, so perhaps it can force the tracee to memcpy() its "vvar" memory.
Can this work with gdbserver? Again, I do not think this hack can make any
sense. I am just curious.

At least (I hope) this mapping doesn't look "important" from debugging pov,
perhaps gdb should ignore it. Lets see what Andy thinks, but I bet it is
very unlikely that the kernel will be changed to allow the access to this
vma.

Oleg.