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