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

["Michael Teske" <mteske at csksoftware dot com>]

On Tuesday 25 February 2003 14:28, Geoff Keating wrote:

[snip]

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

As I do much under Solaris I think they try to implement a 
DeathStation9000(TM). Everything not guaranteed to work will not work.

> > 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?

I'll try to find out, but the offset seems to play a role here, too.
Since you don't specify an offset to mmap when writing the file, you get a 
different base. In my tests I get 0xff390000 with offset 0 and  0xff396000
with offset 16000 (as it happens to be in my test pch file). It seems that 
Solaris mmaps "in reality" the file from 0x10000 and then just adds 
(offset & 0xffff) to the base.

> > 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), 

Might still be an improvement over parsing all the headers (I have to use 
Orbacus, whose headers are full of complicated template stuff).

> but it'd be much better
> to get this to work.

Of course.

> 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?

Have to look at that, but that might be too os specific, or not?

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

Of course this would imply that one can't use a pch file generated on one 
machine on another machine safely without relocating :(



-- 
Michael Teske
<This space is left blank intentionally>