[Help-smalltalk] Re: How does linking work under Solaris? [fwd]

[Paolo Bonzini]

--- Original message ---
Author: Casper Dik <address@hidden>
Date: Wed, 6 Dec 2000 10:50:32 +0100 (MET)
Subject: Re: How does linking work under Solaris?

In comp.sys.sun.misc you write:

>GNU Smalltalk (which I mantain) uses mmap with MAP_FIXED to allocate its
>heaps.  If they are allocated in a precise area (around 0xef7c000) it
>breaks multiplication and (I think, I have no machine to check this
>claim) any other call to libc.  This happens on smaller test programs
>too; here is what a user wrote:

>  Well I tried a few things:
>  1. I wrote a stupid little prog. It does a simple multiplication
>  [...] and once again .umul is called. .umul calls the _PROCEDURE_
>  LINKAGE_TABLE and there is the call to the same absolute address as
>  before: 0xef7c2f7c. I did with gcc and c89 (ansi c compiler).
> 
>  Than I wrote a little mmap application that makes 2 mmaps like yours
>  one on 0xdf770000 and the following one at 0xef770000, after the 2nd
>  mmap a nice multiplication. I compiled this prog with both gcc and
>  c89. Exactly the same behavior [as GNU Smalltalk], exactly the same
>  problem [i.e. crash with a SIGSEGV as soon as PC=0xef7c2f7c].

>Why does dynamic linking use absolute addresses rather than position
>independent code? If it is not dynamic linking, why isn't the area where
>I do the mmaps protected? One other Solaris user reported that the Sun
>compiler creates a working executable -- was it just luck or not?

If you use "MMAP_FIXED" you are asking for trouble.

The program is presumably linked with libc; this will be mapped
first directly under the stack.  A MAP_FIXED later will overwrite
the libc mapping and destroy any chance your progam has of working.

Your  precise mapping may work on some systems as it largely depends
on where the stack starts; the addresses for stack top (top of
address space) are:


        0xe0000000              - sun4d,
                                  SS1000/SC2000 first large Sun MP systems,
                                  (really old Solaris releases use 0xf0000000
                                  on these systems)
                                  0xef7...... mappings will fail as they're
                                  not a valid part of the address space.

        0xf0000000              - non-UltraSPARC and Ultra prior to S7
                                  mapping conflicts with libc and other
                                  libraries, program will die.

        0xffbf0000              - UltraSPARC 32 bit programs, S7 and later.
                                  mapping will probably work as libraries
                                  map above 0xf0000000, typically


Casper


-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.