Re: shared memory load address and gcl
Hi.
I think my conceptual question is now clearer. My experience with
linux tells me that sbrk'ed memory cannot overrun the address used for
shared memory maps. But on asdfasdf, there appears at first blush no
such problem. Can this possibly be right? Should I ignore this
apparent ceiling to the lisp heap on bsd?
./yy
34359738368 34359738368 0x600a88 0x600a88 0x1600a88
echo $?
0
ldd ./yy
libc.so.0.1 => /lib/libc.so.0.1 (0x0000000801256000)
/lib/ld-kfreebsd-x86-64.so.1 => /lib64/ld-kfreebsd-x86-64.so.1 (0x0000000001021000)
The call to get same mapping as in ldd is
$ /lib/ld-2.10.2.so ./yy
34359738368 34359738368 0x600a88 0x600a88 0x1600a88
Segmentation fault
And yes, there is a problem :-(
In this case, the 1st ELF loaded is ld.so,
it looks like we (GNU/kFreeBSD) have problem
with brk()/sbrk() in such environment.
Some gathered informations:
The standard text start, i.e. usual load address of ET_EXEC is
amd64: 0x00400000
i386: 0x08048000
The load address of all ET_DYN (including ld.so) as 1st ELF is
7.2 both: 0x20000000
8.0 amd64: 0x01021000
8.0 i386: 0x01001000
When 1st ELF is the binary, the ld.so is placed via mmap,
i.e. into standard memory area after largest allowed
data segment, usually 32GB on amd64 and 512MB on i386.
amd64: 0x80060a000
i386: 0x28051000
Iff you would be altering linker script anyway, please use as text start
0x02000000 on both plaforms. It should give enouch memory for heap and
when started via /lib/ld-2.10.2.so
under 8.0 it would be located after ld.so,
under 7.2 there would at least 400MB before overrun of ld.so happens.
Petr
Reply to: