> Date: Thu, 19 May 2011 03:32:10 +0200 > From: Ariane van der Steldt <ari...@stack.nl> > > Hi, > > I would respond in-thread, but I can't find the thread that had the > original report that emacs-22 doesn't work under vmmap. Perhaps it was > only on icb... > > Anyways, emacs-22.3p8 doesn't work under vmmap on i386. And the lovely > thing is, it's not my bug. :)
Sorry, but I disagree. A kernel without the vmmap diff loads these binaries just fine. I fear I don't fully grok what vmmap is doing, but I suspect it is too strict. > Emacs, by way of elf commands, insists on having the data area > (ep_daddr) start at address 0x81bd000 (approx 136MB). This means that, > starting at that address, a huge amount of memory (BRKSIZ + MAXDSIZ = > 3GB) is unavailable to load libraries. While it would be nice to avoid BRKSIZ, there's nothing wrong with eating into that area if you really need to. Especially in the case of emacs where that area has been dumped into the binary itself. I don't understand why you mention MAXDSIZ here; that's not really an "area". And it is perfectly fine to load shared libraries between the area reserved for the heap and the area reserved for the stack. > Normally, this is not a problem (try this on sparc and it just works, > for example). But i386 is special in the way it handles W^X requiring > approx 512MB to load libraries (this presentation explains it all: > http://www.openbsd.org/papers/ven05-deraadt/index.html ). Well, W^X on i386 has always been a best effort. If your binary is laid out in a way that doesn't allow us to keep all code below the "exec" line, we still allow the application to run without W^X protection. > Short story long, emacs fails to load its libraries into the area it > reserved for brk() and our ld.so, noticing it is asked to work miracles > here, rightfully objects. So this is where I disagree I guess. Without your diff, ld.so doesn't object or doesn't think it needs to work miracles at least.
