[Top][All Lists]

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

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]