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

[Pedro Alves <palves@redhat.com>]

On 03/12/2015 04:05 PM, Oleg Nesterov wrote:
> 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.

Not currently, it can't.

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

Yes, that can work.  But it's horrible.  :-)  If the user is dumping the
process's core, it's likely because the traced process is already in a
not-so-good / corrupted state.  Forcing it to run more code may make
things worse.

> At least (I hope) this mapping doesn't look "important" from debugging pov,
> perhaps gdb should ignore it. Lets see what Andy thinks, 

Agreed, let's hear what Andy says.

> but I bet it is
> very unlikely that the kernel will be changed to allow the access to this
> vma.

Thanks,
Pedro Alves