This is the mail archive of the 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 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.

GPG key ID: 0x65FC5E36
Please send encrypted e-mail if possible

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