From owner-freebsd-current Tue Sep 1 20:24:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA23556 for freebsd-current-outgoing; Tue, 1 Sep 1998 20:24:20 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA23550 for ; Tue, 1 Sep 1998 20:24:18 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id NAA26285; Wed, 2 Sep 1998 13:23:16 +1000 Date: Wed, 2 Sep 1998 13:23:16 +1000 From: Bruce Evans Message-Id: <199809020323.NAA26285@godzilla.zeta.org.au> To: bde@zeta.org.au, jdp@polstra.com Subject: Re: ELF binaries size Cc: current@FreeBSD.ORG, reilly@zeta.org.au Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>But a.out has a repeat of the same situation at the juncture of data >>and bss, and ELF does not. I wrote: >No it doesn't. The bss immediately follows the data. The data section >is padded to 4K in the file for some reason. I was a bit confused. size(1) shows that the "data" section itself is padded. I was thinking of the actual data section, which ends at edata. Part of the bss is merged into the data section to avoid wasting in-core space given that we're wasting file space (this results in a bss size of 0 for small programs). The reason for the padding is that it simplifies paging. It may even be faster, since disk blocks are always padded. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message