Date: Tue, 1 Sep 1998 23:51:27 -0500 (CDT) From: Joel Ray Holveck <joelh@gnu.org> To: bde@zeta.org.au Cc: bde@zeta.org.au, jdp@polstra.com, current@FreeBSD.ORG, reilly@zeta.org.au Subject: Re: ELF binaries size Message-ID: <199809020451.XAA04004@detlev.UUCP> In-Reply-To: <199809020323.NAA26285@godzilla.zeta.org.au> (message from Bruce Evans on Wed, 2 Sep 1998 13:23:16 %2B1000) References: <199809020323.NAA26285@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>But a.out has a repeat of the same situation at the juncture of data >>>and bss, and ELF does not. >> 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. Say, while I was looking at this, I noticed something... Didn't we used to have an a.out-friendly objdump? I'm running a 26Aug current. (I'm willing to wait a few days for the ELF world, having no ELF-critical projects today.) The only objdump is directly in /usr/libexec/elf, and it won't read a.out (natch). What happened to the old objdump? Best, joelh -- Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809020451.XAA04004>