Chuck Silvers wrote:

> there's another option, which is what the other VIPT-cache platforms do:
> put the text and data right together in the file, but map the page
> containing the text/data boundary twice:

> 
> sparc:
>  10 .rodata       000000e8  00010bd8  00010bd8  00000bd8  2**3
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>  11 .data         0000000c  00020cc0  00020cc0  00000cc0  2**2
>                   CONTENTS, ALLOC, LOAD, DATA
> 
> sparc64:
>  10 .rodata       000000c0  0000000000100c70  0000000000100c70  00000c70  2**3
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>  11 .data         00000008  0000000000200d30  0000000000200d30  00000d30  2**3
>                   CONTENTS, ALLOC, LOAD, DATA
> 
> hppa:
>  10 .rodata       00000045  00100bf0  00100bf0  00000bf0  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>  11 .copyright    00000064  00100c38  00100c38  00000c38  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>  12 .PARISC.unwind 00000100  00100c9c  00100c9c  00000c9c  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>  13 .data         00000028  00200d9c  00200d9c  00000d9c  2**2
>                   CONTENTS, ALLOC, LOAD, DATA
> 
> 
> is this style permitted by the MIPS ELF spec?

Indeed, this is suggested by the spec in the "Program Loading" section.
There's this:

	Figure 5-1: Example Executable File

             file           file             virtual
            offset                           address

                 0        text segment
                           ELF header
                      --------------------
                      program header table
                      --------------------
                       other information      0x400100
                      --------------------
             0x100           ....              
                         0x2be00 bytes        0x42beff
                      --------------------
           0x2bf00           ....              
                         0x2be00 bytes        0x440cff
                      --------------------
           0x30d00     other information       
                             ....              
                      --------------------

and talks in the text about the file region holding the end of text and
start of data being mapped twice ad two different virtual addresses
exactly as you suggest.

However, short term I'd still like to go with the first two options
since they're simple and we have the changes from binutils alread to
implement them.

Longer term, I'll ask on the binutils list about the dual mapping of end
of text/start of data.

Thanks,
Simon.
--
Simon Burge                            <simonb@wasabisystems.com>
NetBSD Support and Service:         http://www.wasabisystems.com/