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: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Sergio Durigan Junior <sergiodj at redhat dot com>
- Cc: GDB Patches <gdb-patches at sourceware dot org>, Pedro Alves <palves at redhat dot com>, Oleg Nesterov <oleg at redhat dot com>
- Date: Thu, 5 Mar 2015 21:57:44 +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>
On Thu, 05 Mar 2015 21:52:56 +0100, Sergio Durigan Junior wrote:
> On Thursday, March 05 2015, Jan Kratochvil wrote:
> > On Thu, 05 Mar 2015 04:48:09 +0100, Sergio Durigan Junior wrote:
> >> With Oleg's help, we could improve the current algorithm for determining
> >> whether a memory mapping is anonymous/file-backed, private/shared. GDB
> >> now also respects the MADV_DONTDUMP flag and does not dump the memory
> > s/does not dump/does dump/
> No, it doesn't dump. MADV_DONTDUMP activates the "dd" flag in VmFlags,
> and the patch looks for it and, if it finds the flag, it doesn't mark
> the memory mapping to be dumped. However, GDB will create the section
> header in the corefile.
Sorry, I meesed it up even more. For MADV_DONTDUMP you are right, FSF GDB
dumps MADV_DONTDUMP memory, kernel does not and with this patch GDB will not.
What I wanted to say was:
> >> mapping marked as so, and won't try to dump "[vsyscall]" or "[vdso]"
s/won't try/will try/
> >> mappings as before (just like the Linux kernel).
> > Currently it also tries to dump [vvar] (by default rules) but that is
> > unreadable for some reason, causing:
> > warning: Memory read failed for corefile section, 8192 bytes at 0x7ffff6ceb000.
> > ^^^^^^^^^^^^^^
> > Saved corefile /tmp/1j
> > (gdb) _
> > # grep 7ffff6ceb000 /proc/$p/maps
> > 7ffff6ceb000-7ffff6ced000 r--p 00000000 00:00 0 [vvar]
> > ^^^^^^^^^^^^ ^^^^
> > I do not know what [vvar] is good for and why it cannot be read.
> I totally forgot about this, even though we discussed it before. Sorry;
> I am sending a new version of the patch which addresses this issue.
It would be good to get a reply from a kernel aware person what does it mean
before such patch gets accepted. It can be also just a Linux kernel bug.