Date: Mon, 9 Dec 2002 13:00:13 -0800 (PST) From: "Peter Edwards" <pmedwards@eircom.net> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/45994: Pages marked read-only via mprotect are zeroed in core files Message-ID: <200212092100.gB9L0DHU020942@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/45994; it has been noted by GNATS.
From: "Peter Edwards" <pmedwards@eircom.net>
To: archie@packetdesign.com, freebsd-gnats-submit@freebsd.org
Cc:
Subject: Re: kern/45994: Pages marked read-only via mprotect are zeroed in core files
Date: Mon, 9 Dec 2002 20:55:47 +0000
Hi,
sys/kern/imgact_elf.c's each_writable_segment iterates over the processes
vm map, and works out what pages need to go into the core file. It ignores
any vm entries that are not read/write, as well as those marked with a
"no coredump" flag.
In order to get the elf image activator to dump read-only data in the core
file, you need to allow this to output readonly segments.
The patch below does that, by adding a debug sysctl, "debug.elf_bigcore".
However, note that this will dump _any_ segment that is readonly, including
text segments and read-only segments from executables. This will make the
core files quite large, particularly for programs that load a lot of shared
libraries. It might, however, allow you to debug a problem more easily than
you were able to before, so I hope its useful.
I imagine a more complete fix is to start using MAP_NOCORE properly, so
that both the dynamic linker and the kernel itself use it on readonly
sections of loaded executables.
If anyone agrees, I'm willing to submit patches to elf_imgact and rtld_elf
to do that: I just don't want to do the grunt-work if no one's interested.
--
Peter Edwards.
diff -u -r1.73.2.11 imgact_elf.c
--- imgact_elf.c 9 Sep 2002 17:38:47 -0000 1.73.2.11
+++ imgact_elf.c 9 Dec 2002 20:22:59 -0000
@@ -79,7 +79,10 @@
static int exec_elf_imgact __P((struct image_params *imgp));
static int elf_trace = 0;
+static int elf_bigcore = 0;
+
SYSCTL_INT(_debug, OID_AUTO, elf_trace, CTLFLAG_RW, &elf_trace, 0, "");
+SYSCTL_INT(_debug, OID_AUTO, elf_bigcore, CTLFLAG_RW, &elf_bigcore, 0, "");
static struct sysentvec elf_freebsd_sysvec = {
SYS_MAXSYSCALL,
@@ -493,6 +496,11 @@
* From this point on, we may have resources that need to be freed.
*/
+ if ((error = exec_extract_strings(imgp)) != 0)
+ goto fail;
+
+ exec_new_vmspace(imgp);
+
/*
* Yeah, I'm paranoid. There is every reason in the world to get
* VTEXT now since from here on out, there are places we can have
@@ -503,11 +511,6 @@
imgp->vp->v_flag |= VTEXT;
simple_unlock(&imgp->vp->v_interlock);
- if ((error = exec_extract_strings(imgp)) != 0)
- goto fail;
-
- exec_new_vmspace(imgp);
-
vmspace = imgp->proc->p_vmspace;
for (i = 0; i < hdr->e_phnum; i++) {
@@ -887,6 +890,7 @@
vm_object_t obj;
if ((entry->eflags & MAP_ENTRY_IS_SUB_MAP) ||
+ !elf_bigcore &&
(entry->protection & (VM_PROT_READ|VM_PROT_WRITE)) !=
(VM_PROT_READ|VM_PROT_WRITE))
continue;
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200212092100.gB9L0DHU020942>