other/9830: [pch] not working on Solaris 9

Geoff Keating geoffk@geoffk.org
Tue Feb 25 13:29:00 GMT 2003


> From: "Michael Teske" <mteske@csksoftware.com>
> Date: Tue, 25 Feb 2003 13:03:51 +0100

> On Tuesday 25 February 2003 10:41, Michael Teske wrote:
> 
> > As I saw it in gdb, Solaris seems to always return
> > (mmi.preferred_base + mmi.offset) as addr. I'll try what happens if I pass
> > mmi.preferred_base-mmi.offset as the first parameter (if MAP_FIXED is not
> > given).
> 
> Hmm, this all doesn't help. Here's what the man page says:
> 
>    When MAP_FIXED is not set, the system uses addr to arrive at
>      pa.  The  pa  so chosen will be an area of the address space
>      that the system deems suitable for a mapping of len bytes to
>      the file.  The mmap() function interprets an addr value of 0
>      as granting the system complete  freedom  in  selecting  pa,
>      subject  to constraints described below. A non-zero value of
>      addr is taken to be a suggestion of a process  address  near
>      which  the mapping should be placed. When the system selects
>      a value for pa, it will never place a mapping at address  0,
>      nor  will  it replace any extant mapping, nor map into areas
>      considered part of the potential data or stack "segments".
> 
> So it takes it as a suggestion _near_ where the data should arrive, it doesn't 
> even try to use the exact address :-( My test program confirm this.
> Consider this small little test program:
> #include <stdio.h>
> #include <sys/mman.h>
> 
> int main(void) {
>   void* base = 0xff3A0000;
>   long size = 0x2000;
>   long offset = 0x16000;
>   void* addr;
> 
>   FILE *f = fopen ("mmaptest.bigfile", "r+");
> 
>   if (f==NULL) return 1;
>   addr = mmap (base, size,
>                PROT_READ | PROT_WRITE, MAP_PRIVATE,
>                fileno (f), offset);
>   printf("base: %p, addr: %p\n", base, addr);
>   /* cleanup omitted */
> 
>   return 0;
> }
> 
> It always gives me 0xff396000 as addr back, regardless if I feed in 
> 0xff3A0000, 0xff380000, or even 0xff000000 as base :-(((

*sigh*.  I wonder what the Solaris designers were thinking?

> If I set offset to 0, it returns 0xff390000, regardless of input, so this is 
> not a solution, either :-( 

So, why doesn't the code that generates the PCH file get the same
address as the code that imports it?  Is it dependent on previous
mappings in some way?

> The only way seems to be MAP_FIXED or a correct implementation of
> relocation a PCH file.

The problem with relocating the PCH is that you lose a lot of the
speed benefits.  It can be done (all the support is there, it's just a
question of writing maybe 20 lines of code), but it'd be much better
to get this to work.

MAP_FIXED would work if you can find a way to work out whether there's
already something else mapped at that location.  I don't have a
Solaris box right now, but I seem to remember that you could read
memory map information out of /proc?

> And I just tested on a different machine with Solaris 8, same there,
> just the fixed value is another one.

Yuk.

-- 
- Geoffrey Keating <geoffk@geoffk.org>



More information about the Gcc-bugs mailing list