Mail Archives: cygwin/2012/07/13/10:28:22
On Jul 13 07:52, Reini Urban wrote:
> On Fri, Jul 13, 2012 at 2:40 AM, Corinna Vinschen wrote:
> > On Jul 12 20:48, Daniel Colascione wrote:
> >> On 7/10/12 8:41 AM, Daniel Colascione wrote:
> >> > On 7/10/12 1:13 AM, Corinna Vinschen wrote:
> >> >> On Jul 9 21:59, Daniel Colascione wrote:
> >> >>> On 7/9/12 2:26 PM, Daniel Colascione wrote:
> >> >>>> [snip]
> >> >>>
> >> >>> It turns out that clisp crashes only when I've rebased DLLs into the
> >> >>> high portion of the 4GB WOW64 address space.
> >> >>
> >> >> Where did you rebase them to? You know that on WOW64 and with the
> >> >> bigaddr flag on, the application heap is located at 0x80000000 by
> >> >> default, right? Perhaps some of your DLLs just collide with that?
> >> >
> >> > I'm using a starting base address of 0xC8000000; I haven't had
> >> > problems with any other program.
> >>
> >> It turns out that clisp uses bit 31 of each pointer for its gc mark
> >> bit. No wonder the thing blows in bigaddr-aware mode. clisp _does_
> >
> > Ouch.
> >
> >> work, however, when compiled with -DWIDE. In this mode, clisp uses two
> >> words for each lisp value --- one for the pointer and one for the
> >> metadata.
>
> Hmm, I do not really want to maintain lisp32.exe and lisp64.exe
> variants, but maybe
> upstream can be persuaded to make that distinction in the clisp.exe driver.
> It's only for huge data and bad rebase addresses.
> And for huge data a self-compiled clisp makes sense to me.
> Serious lisp users use better lisp compilers anyway which compile
> to native code. (sbcl, lispworks, allegro).
> clisp's main strength is fast startup and fast IO.
>
> >> Also, clisp has a LINUX_NOEXEC_HEAPCODES mode that also
> >> works, and without bloating memory use, but that requires that no real
> >> virtual address be in the range [0xC0000000, 0xDFFFFFFF].
> >
> > That can't be guaranteed. WOW64 provides the full 32 bit VM address
> > space.
>
> Maybe also a documentation issue for rebaseing.
That has nothing to do with rebasing. If you build clisp with a recent
gcc, it will have the "bigaddr" flag set in the file header since
Cygwin's gcc sets that by default. While DLLs should be rebased from
0x70000000 downwards as usual, the applications heap, as well as
thread stacks, as well as shared memory regions created with mmap(2)
or shmat(2) will be in the high memory area starting at 0x80000000.
THe bottom line is, if the distro clisp isn't 32 bit clean, which it
apparently isn't using default settings, it should either be rebuilt
with -DWIDE, or it should have the bigaddr flag removed from the
file header by default (peflags -l0).
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -