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: Pedro Alves <palves at redhat dot com>
- To: Sergio Durigan Junior <sergiodj at redhat dot com>, GDB Patches <gdb-patches at sourceware dot org>
- Cc: Jan Kratochvil <jan dot kratochvil at redhat dot com>, Oleg Nesterov <oleg at redhat dot com>
- Date: Fri, 13 Mar 2015 19:37:31 +0000
- 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>
On 03/05/2015 03:48 AM, Sergio Durigan Junior wrote:
> In a nutshell, what the new code is doing is:
>
> - If the mapping is associated to a file whose name ends with "
> (deleted)", or if the file is "/dev/zero", or if it is "/SYSV%08x"
> (shared memory), or if there is no file associated with it, or if the
> AnonHugePages: or the Anonymous: fields in the /proc/PID/smaps have
> contents, then GDB considers this mapping to be anonymous. Otherwise,
> GDB considers this mapping to be a file-backed mapping (because there
> will be a file associated with it).
>
> It is worth mentioning that, from all those checks described above,
> the most fragile is the one to see if the file name ends with "
> (deleted)". This does not necessarily mean that the mapping is
> anonymous, because the deleted file associated with the mapping may
> have been a hard link to another file, for example. The Linux kernel
> checks to see if "i_nlink == 0", but GDB cannot easily do this check.
> Therefore, we made a compromise here, and we assume that if the file
> name ends with " (deleted)", then the mapping is indeed anonymous.
> FWIW, this is something the Linux kernel could do better: expose this
> information in a more direct way.
>
> - If we see the flag "sh" in the VmFlags: field (in /proc/PID/smaps),
> then certainly the memory mapping is shared (VM_SHARED). If we have
> access to the VmFlags, and we don't see the "sh" there, then certainly
> the mapping is private. However, older Linus kernels do not have the
> VmFlags field; in that case, we use another heuristic: if we see 'p'
> in the permission flags, then we assume that the mapping is private,
> even though the presence of the 's' flag there would mean VM_MAYSHARE,
> which means the mapping could still be private. This should work OK
> enough, however.
I missed seeing a git commit log in v2, but looking here, I think
it'd be good to move paragraphs to the code instead, to a general
overview section, even.
Thanks,
Pedro Alves