This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: emacs and large-address awareness under recent snapshots


On 8/8/2011 2:20 PM, Achim Gratz wrote:
Corinna Vinschen<...> writes:
still tries to workaround some old problem in the Cygwin sbrk
implementation in Cygwin 1.5.  Unfortunately the comment doesn't contain
any hint as to what exact problem this code is trying to workaround.

Apologies if that's obvious and you've already checked that: emacs gets created as a dumpfile of temacs during build, so if peflags moves the heap retroactively thereafter I can't see how it's going to work since part of the heap is where it was during dumping and the rest is, well, somewhere else. I'd look at the build process first before suspecting the sources â I would assume that temacs must also be made large address aware and that it right now just isn't. There may still be workarounds that aren't needed anymore and bad assumptions about how the memory map looks like in Cygwin.

Thanks for the suggestion, but that doesn't seem to be the issue. I just tried building emacs with LDFLAGS=-Wl,large-address-aware. That should have made temacs and the dumpfile large address aware. The result was that the build didn't finish. bootstrap-emacs.exe compiled a bunch of .el files and then started spinning its wheels, just as in my report earlier in this thread. Attaching gdb and getting a backtrace, I again found that emacs was stuck in morecore_nolock, called from _malloc_internal_nolock.


Corinna, here's some explanation of the above (and of unexec, which you were wondering about.) The build process for emacs first compiles the C source files into an executable temacs.exe, which has no editing commands. It then runs temacs.exe, which loads some lisp files to set up the editing environment and then dumps itself as emacs.exe. The dumping is done by unexec, which is defined in unexcw.c. I think that the data in the static heap (from sheap.c) is part of what gets dumped, so emacs defines a special version of sbrk (called bss_sbrk) that simulates sbrk but uses the static heap instead of the ordinary application heap.

I don't think emacs is trying to work around problems in Cygwin's sbrk. In fact, emacs.exe, as opposed to temacs.exe, does use Cygwin's sbrk. You can see this in the function __default_morecore in gmalloc.c, which calls bss_sbrk if emacs.exe hasn't yet been dumped (i.e., if temacs.exe is running) and Cygwin's sbrk otherwise.

I hope this all makes sense and is correct. It may or may not be relevant to figuring out what goes wrong when the ordinary heap starts at 0x80000000.

Ken


-- 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]