This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Improve corefile generation by using /proc/PID/coredump_filter (PR corefile/16902)
- From: Pedro Alves <palves at redhat dot com>
- To: Oleg Nesterov <oleg at redhat dot com>
- Cc: Jan Kratochvil <jan dot kratochvil at redhat dot com>, Sergio Durigan Junior <sergiodj at redhat dot com>, GDB Patches <gdb-patches at sourceware dot org>
- Date: Thu, 12 Mar 2015 16:28:16 +0000
- Subject: Re: [PATCH] Improve corefile generation by using /proc/PID/coredump_filter (PR corefile/16902)
- Authentication-results: sourceware.org; auth=none
- References: <878ufc9kau dot fsf at redhat dot com> <20150305154827 dot GA9441 at host1 dot jankratochvil dot net> <87zj7r5fpz dot fsf at redhat dot com> <20150305205744 dot GA13165 at host1 dot jankratochvil dot net> <20150311200052 dot GA22654 at redhat dot com> <20150312150024 dot GA4817 at redhat dot com> <5501B48B dot 7060802 at redhat dot com> <20150312160551 dot GA8144 at redhat dot 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