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: Sergio Durigan Junior <sergiodj at redhat dot com>
- To: Oleg Nesterov <oleg at redhat dot com>
- Cc: Jan Kratochvil <jan dot kratochvil at redhat dot com>, GDB Patches <gdb-patches at sourceware dot org>, Pedro Alves <palves at redhat dot com>
- Date: Thu, 12 Mar 2015 13:37:25 -0400
- 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>
On Thursday, March 12 2015, Oleg Nesterov wrote:
>> Probably gdb doesn't need to dump this vma, but see below.
>
> Probably yes. Note that it has VM_DONTDUMP ("dd" in "VmFlags:" field).
The fact that the region has VM_DONTDUMP is enough for GDB to ignore
it. IMO, as discussed in the other thread with Andy, the Linux kernel
is bogus in this case and should also be ignoring this.
> 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.
Yeah, but I don't think this is worth the effort. As Pedro mentioned,
things can get more complicated when we consider remote scenarios.
> (just in case, "vdso" is the same too but it is MAYWRITE, so it can have
> anonymous pages. Say, breakpoints installed by gdb).
Also, [vdso] doesn't have the VM_DONTDUMP flag. My patch is already
dumping it inconditionally.
--
Sergio
GPG key ID: 0x65FC5E36
Please send encrypted e-mail if possible
http://sergiodj.net/