Date: Mon, 9 Dec 2002 15:10:02 -0800 (PST) From: Archie Cobbs <archie@packetdesign.com> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/45994: Pages marked read-only via mprotect are zeroed in core files Message-ID: <200212092310.gB9NA22X062721@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: Archie Cobbs <archie@packetdesign.com> To: Peter Edwards <pmedwards@eircom.net> Cc: freebsd-gnats-submit@freebsd.org Subject: Re: kern/45994: Pages marked read-only via mprotect are zeroed in core files Date: Mon, 09 Dec 2002 15:03:37 -0800 Peter Edwards wrote: > 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. Thanks! > 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. I think this is a necessary change, so I at least would be interested. There are lots of important uses for mapping pages read-only, e.g., when using malloc debugging libraries such as electric fence, etc. Moreover, the current behavior is broken, plain and simple. It sounds like the MAP_NOCORE change would not cost any performance, in which case I don't see why anyone would object to it. Thanks! -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com 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?200212092310.gB9NA22X062721>