This is the mail archive of the
glibc-bugs@sources.redhat.com
mailing list for the glibc project.
[Bug libc/387] ld-linux.so has its name in ro_data in link_map entry => problem in core files
- From: "jcownie at etnus dot com" <sourceware-bugzilla at sources dot redhat dot com>
- To: glibc-bugs at sources dot redhat dot com
- Date: 27 Sep 2004 10:31:37 -0000
- Subject: [Bug libc/387] ld-linux.so has its name in ro_data in link_map entry => problem in core files
- References: <20040916101402.387.jcownie@etnus.com>
- Reply-to: sourceware-bugzilla at sources dot redhat dot com
------- Additional Comments From jcownie at etnus dot com 2004-09-27 10:31 -------
Subject: Re: ld-linux.so has its name in ro_data in link_map entry => problem in core files
> If anything this sounds like a kernel bug to me.
> It should dump even read-only VMAs that are MAP_PRIVATE and have been modified
> (i.e. they contain data that you can't get from other sources).
The relevant function in the kernel appears to be this (fs/binfmt_elf.c)
989 /*
990 * Decide whether a segment is worth dumping; default is yes to be
991 * sure (missing info is worse than too much; etc).
992 * Personally I'd include everything, and use the coredump limit...
993 *
994 * I think we should skip something. But I am not sure how. H.J.
995 */
996 static int maydump(struct vm_area_struct *vma)
997 {
998 /*
999 * If we may not read the contents, don't allow us to dump
1000 * them either. "dump_write()" can't handle it anyway.
1001 */
1002 if (!(vma->vm_flags & VM_READ))
1003 return 0;
1004
1005 /* Do not dump I/O mapped devices! -DaveM */
1006 if (vma->vm_flags & VM_IO)
1007 return 0;
1008 #if 1
1009 if (vma->vm_flags & (VM_WRITE|VM_GROWSUP|VM_GROWSDOWN))
1010 return 1;
1011 if (vma->vm_flags & (VM_READ|VM_EXEC|VM_EXECUTABLE|VM_SHARED))
1012 return 0;
1013 #endif
1014 return 1;
1015 }
It seems you're suggesting that the condition on line 1011 needs
changing ?
The inclusion of VM_READ there seems a little odd to me anyway, since we
already know (from the test at line 1002) that VM_READ must be set, and
therefore the whole test at line 1011 is guaranteed to succeed and cause
the function to return 0.
--
http://sources.redhat.com/bugzilla/show_bug.cgi?id=387
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.