emacs-devel
[Top][All Lists]
Advanced

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

Re: Some OpenWrt port related problems


From: David Kuehling
Subject: Re: Some OpenWrt port related problems
Date: Sun, 02 Jan 2011 14:53:47 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

>>>>> "Ken" == Ken Raeburn <address@hidden> writes:

> On Jan 1, 2011, at 10:34, Eli Zaretskii wrote:
>>> From: David Kuehling <address@hidden> Date: Sat, 01 Jan 2011
>>> 15:20:58 +0100 Cc: address@hidden, Emacs Dev <address@hidden>

>>> Finding pointers to doc strings...done emacs: Can't allocate buffer
>>> for /usr/bin/emacs
>>> 
>>> So it wants to pull a full copy of the emacs binary into memory?
>> 
>> It tries to mmap it, yes:

> Contrary to the comment in unexelf.c saying "We do not use mmap
> because that fails with NFS." :-)

> Perhaps we could reduce the memory requirement a bit by (in the ELF
> case) mapping the ELF header and read-only sections as shared,
> read-only data, so the process wouldn't need space from the OS for
> private modifications to those pages.  

Well, if those pages are not modified, no memory is needed from the OS
anyway (i.e. copy-on-write/lazy copy).  Just that linux VM manager seems
to usually check whether it has enough pages just-in-case.

Similar problems seem to crop up with fork();exec() inside emacs.  So
enabling overcommitting on the NanoNote may be a good thing in general.

[..]
> I did a MIPS32 (Lemote laptop) GNU/Linux build of the latest alpha
> snapshot; no error was produced.  According to "readelf -e", temacs
> has no .sbss section.  The on-disk part of segment 4 does end at the
> start of BSS, and it's the segment with the highest memory address
> (not file offset) overall, so there's nothing mapped higher than the
> BSS.  So I'm afraid I can't help much, at least without more info
> (e.g., "readelf -e temacs", to see how it's different from mine).  And
> I'm not sure I know enough about the linker view on MIPS to help
> anyways.

  $ readelf -t /usr/bin/emacs

  There are no sections in this file.

:) 

Could it be that 'sstrip' (that's no typo, it's not vanilla 'strip')
used for openwrt packages causes collateral damage here?  Emacs won't be
the only package effected.

David
-- 
GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205  D016 7DEF 5323 C174 7D40

Attachment: pgpnlzcW0N_Dl.pgp
Description: PGP signature


reply via email to

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