[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: shared memory load address and gcl

From: Camm Maguire
Subject: [Gcl-devel] Re: shared memory load address and gcl
Date: Wed, 03 Feb 2010 11:43:30 -0500
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

Greetings, and thank you *so much* for your clear and helpful reply.
I will instruct the linker script as you say for the next upload.

This issue primarily was a configuration issue on kamd64 8.0, as the
ceiling address to the heap was determined to be too low
unnecessarily.  Configuring the addresses by hand appears to work

Separately, I'm having trouble reproducing the buildd failure on kx86
on io sid chroot.  Both machines have identical memory address layouts
as reported by configure.  The failure lies in a test routine
involving gmp if this helps.  Any ideas why there should be a
difference here?

Take care,

Petr Salinger <address@hidden> writes:

> 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

Camm Maguire                                        address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]