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: Ken Raeburn
Subject: Re: Some OpenWrt port related problems
Date: Sun, 2 Jan 2011 15:35:27 -0500

On Jan 2, 2011, at 08:53, David Kuehling wrote:
> 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.

Eh.. I've never been convinced that it's a good thing.  I like the fact that 
mmap/malloc can fail, and give you a chance to recover, rather than simply 
having a process blown out of the water when it turns out that a page isn't 
actually available after all.  But that's just me....

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

Okay, then you are doing something different...  I don't know how unexelf.c is 
going to handle a file with no section headers.  As best I recall, they're not 
critical for execution, but unexelf.c may be making additional assumptions 
based on how other systems tend to operate.  Ideally, I think it should be 
possible to just extent the loadable data sections, but that's not how 
unexelf.c operates.  If you can bypass 'sstrip' for a package, or just one 
executable in the package (emacsclient should be fine to strip, for example), 
that might fix the problem and allow you to have it dump during installation.

Ken


reply via email to

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