This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] Improve corefile generation by using /proc/PID/coredump_filter (PR corefile/16902)
- From: Oleg Nesterov <oleg at redhat dot com>
- To: Pedro Alves <palves 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 17:05:51 +0100
- 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>
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