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)


See another email I sent, perhaps this needs more discussion...

But,

On 03/11, Oleg Nesterov wrote:
>
> On 03/05, Jan Kratochvil wrote:
> >
> > 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:
> > > > 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.
>
> Probably gdb doesn't need to dump this vma, but see below.

Probably yes. Note that it has VM_DONTDUMP ("dd" in "VmFlags:" field).

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.

(just in case, "vdso" is the same too but it is MAYWRITE, so it can have
 anonymous pages. Say, breakpoints installed by gdb).

Oleg.


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