Subject: Re: There is a hole in my ELF
To: None <joda@pdc.kth.se, port-alpha@netbsd.org>
From: Ross Harvey <ross@teraflop.com>
List: port-alpha
Date: 08/10/1998 07:23:40
> From: joda@pdc.kth.se (Johan Danielsson)
>
> While hacking on an ELF aware modload, I stumbled on this GNU-ld
> feature (from elf.sc):
>
>   /* Adjust the address for the data segment.  We want to adjust up to
>      the same address within the page on the next page up.  */
>
> Ok, fine. But why? I can imagine cases where you'd want the data
> segment to start at the next page, but why offset it into the next
> page? IRIX ld seems to put things at the next page boundary.
>
> And why is MAXPAGESIZE 1MB on alpha?
>
> I guess this isn't a problem with ordinary programs, but with the
> present a.out-centric lkm interface, quite a lot of kernel memory gets
> wasted without doing ugly tricks.
>
> Thinking about it, this might perhaps be a tool-chain issue...
>
> /Johan
>

I'm not sure exactly what the toolchain is doing, but there were a couple
of neat tricks discovered long ago.

If you start the data segment at the offset within a page that the text
segment ended with, then you can use the same page on disk (from the image
file) to page in both the last text page and the first data page, thus
saving up to a memory-page of disk space on every adjacent section pair
following this rule. Of course, this applies to any two adjacent sections,
not just to text and data.

The same trick can be used to skip over COFF or ELF headers, too. One begins
the first section at a page boundary plus the size of the file headers.

Actually, you can save pages in main memory too with this, although if the
attributes differ significantly (r/o vs r/w, say), then problems may appear
between adjacent dissimilar sections.

I have no idea what the 1MB issue is. I'm not aware of any 1MB boundaries
in the architecture, at least, none that are associated with VM hardware
or palcode.

  --Ross