From owner-freebsd-hackers Thu Nov 27 16:07:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA02750 for hackers-outgoing; Thu, 27 Nov 1997 16:07:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA02735 for ; Thu, 27 Nov 1997 16:07:03 -0800 (PST) (envelope-from jdp@austin.polstra.com) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.8/8.8.7) with ESMTP id QAA18537; Thu, 27 Nov 1997 16:07:00 -0800 (PST) (envelope-from jdp) Message-Id: <199711280007.QAA18537@austin.polstra.com> To: Charles Mott cc: hackers@FreeBSD.ORG Subject: Re: Shared Libraries and debugging In-reply-to: Your message of "Thu, 27 Nov 1997 16:40:35 MST." Date: Thu, 27 Nov 1997 16:07:00 -0800 From: John Polstra Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > So memory allocated with mmap() is not dumped in a core file? Right. You get the "u" area and the data segment and the stack segment. The data segment is the contiguous region from "etext" up to the sbrk(2) level. I.e., its data + bss + the heap. > Is this not possible Practically anything would be possible. :-) > or just not desirable? Sometimes it might be desirable, and sometimes not. It would require a new core file format that permitted multiple noncontiguous segments. (ELF core files could handle this -- they have the same format as ELF object files.) And of course it would complicate the kernel code that generates core files. And you could end up with some mighty large core files at times. Most mmapped areas are just shared libraries, which still exist on disk. True, they have some data areas that might have been changed by the program, but the data areas in shared libraries are usually relatively small. If you dumped the mmapped areas, you'd probably want to limit it to only the writable regions, on the assumption that the read-only regions could be gotten from the underlying files on disk. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth