On Mon, Mar 28, 2005 at 07:41:50AM -0500, Michael wrote:

> First I thought it's a pthread issue because it /always/ hangs in 
> pthread_sigmask() but the call stack contains some rather funny 
> addresses - shouldn't all (function) pointers have 0 in their upper 32 
> bits when compiled with -mmodel=medlow? It's not the dynamic loader's 

No.  When you run 64-bit code, application code can use the `medlow'
model.  The user space mappings are as follows:

1) The first 1MB or so should be unmapped to prevent NULL pointer
dereferences.  (Actually it should be mapped with the NFO bit set 
to support speculative loads).

2) Next comes the text segment starting at 1MB.

3) The data segment follows.

4) BSS.

5) The malloc(3) heap extends the BSS.  This extends out to 40 bits.
(USI and USII hardware support 41-bit virtual addresses and have a 
sizeable VA hole.  There's also a bug that will lock up certain UI
processors when accessing addresses adjacent to the VA hole.  Using
only 40-bits in the page tables should work around that.  USIII
and USIV support 64-bit VAs and have no VA hole, but we don't support
them yet.)

6) Here's there's a VA hole from 0x000000ffffffffff to 
0xffffff0000000000.

7) From 0xffffff0000000000 to the bottom of the stack hard limit is
the mmap(2) region.  This is where shared libraries are mapped.

8) From the bottom of the stack hard limit to the bottom of the
stack is another VA hole.

9) The stack extends to address 0xffffffffffff1fff.

10) The last page always remains unmapped because the VM subsystem
has issues with the number -1.

So to summarize:

Application code is compiled with `medlow' because the code is
more compact and efficient.  Shared libraries cannot be compiled
with `medlow' because they will not work.  You need to use either
`medany' or the funny 48-bit memory model to compile shared libs.
You can look in /usr/share/mk/* to see what's currently being done.

Eduardo