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


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