From owner-freebsd-current Tue Sep 1 23:59:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA28352 for freebsd-current-outgoing; Tue, 1 Sep 1998 23:59:01 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA28344 for ; Tue, 1 Sep 1998 23:58:59 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id XAA26610; Tue, 1 Sep 1998 23:57:53 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpd026598; Tue Sep 1 23:57:52 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id XAA21156; Tue, 1 Sep 1998 23:57:48 -0700 (MST) From: Terry Lambert Message-Id: <199809020657.XAA21156@usr02.primenet.com> Subject: Re: ELF binaries size To: joelh@gnu.org Date: Wed, 2 Sep 1998 06:57:47 +0000 (GMT) Cc: tlambert@primenet.com, reilly@zeta.org.au, jdp@polstra.com, current@FreeBSD.ORG In-Reply-To: <199809020423.XAA03734@detlev.UUCP> from "Joel Ray Holveck" at Sep 1, 98 11:23:01 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > From reading the sources, I think this does not happen (it would be > > hard to make the vnode pager function in the presence of a unified VM > > and buffer cache, if this were going on ;-)), and the sections are > > loaded starting(/ending) on page boundaries, only for their length. > > Why would that be difficult, with COW? Because there is a single backing object hung off the vp, and thus there's a single mapping; the mapping is either COW, or it's RO code. The way it actually works is to map the same page at different (non-overlapping) locations in the process address space, so it's not a problem in real life... > > What this means is that it takes the same space in core, but less > > space on disk, and that the padding is implied, and an odd boundary > > is seen as a negative offset (i.e., the first part of the first > > data page is mapped, but not valid). Given where the pages come > > from, this should not expose "old data" in the gaps. > > Just out of curiousity... > > IIRC, the bss will be started dw-aligned, yes? Does that mean that > there would be, in theory, some old data in the gap between data and > bss? (iff (edata%4)!=0, of course.) No. There would be a copy of a portion of the text/data, respectively, without the possibility of exploiting either. See John's posting about the mappings; he has pretty pictures, which I (uncharacteristically ;-)) omitted... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message