This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Last data page not being filled
- From: Zack Weinberg <zack at codesourcery dot com>
- To: "D. J. Bernstein" <djb at cr dot yp dot to>
- Cc: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 27 Jun 2003 09:45:30 -0700
- Subject: Re: Last data page not being filled
- References: <20030627070845.6759.qmail@cr.yp.to>
"D. J. Bernstein" <djb@cr.yp.to> writes:
> When a program has (to take a real example) 220 bytes of initialized
> data and 444 bytes of zero-filled data, gcc puts the 220 bytes into the
> data segment and the 444 bytes into the bss segment, frittering away a
> page of memory per process. It should instead put all 664 bytes into the
> data segment.
What you really want, I think, is for the linker to recognize that
there is no need to align the breakpoint between data and bss to a
page boundary. The kernel will zero-fill the last page of the data
segment when it's mapped in, so bss symbols can be stuck into that
space. Since there is no cost whatsoever to this approach (unlike
your original suggestion which would enlarge executables on disk)
there is no reason not to do it unconditionally.
This probably requires changes both to the linker (part of binutils)
and the dynamic loader (part of glibc, for Linux; normally maintained
with the C library of other systems as well).
zw