This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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/

this one.


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


Jan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]