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: vvar, gup && coredump


On Thursday, March 12 2015, Oleg Nesterov wrote:

>> If I understood this discussion correctly (and thanks Andy and Oleg for,
>> *ahem*, dumping all this useful information for us!), GDB will not need
>> modifications in the Linux kernel in this area.  In fact, my patch
>> already implements the "ignore VM_DONTDUMP mappings" part, so we're
>> pretty much covered.
>
> OK, thanks.
>
> And it seems that we all agree that the kernel should not dump this vma
> too. Could you confirm that this is fine from gdb pov just in case?

Yes, this is what we expect from the GDB side.  This mapping is marked
as "dd", so it does not make sense to dump it.

While I have you guys, would it be possible for the Linux kernel to
include a new flag on VmFlags to uniquely identify an anonymous mapping?
Currently, there is no easy way to do that from userspace.  My patch
implements the following heuristic on GDB:

  if (pathname == "/dev/zero (deleted)"
      || pathname == "/SYSV%08x (deleted)"
      || pathname == "<file> (deleted)"
      || "Anonymous:" field is > 0 kB
      || "AnonHugePages:" field is > 0 kB)
    mapping is anonymous;

However, this can be fragile.  The Linux kernel checks for i_nlink == 0,
but there is no easy way for GDB to check this on userspace (as Jan
mentioned, one could look at /proc/PID/map_files/, but they are only
accessible by root).  That's why I think it would be good to provide
this info right away in /proc/PID/smaps...

Thanks,

-- 
Sergio
GPG key ID: 0x65FC5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


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