[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 22:12:30 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
>>>>> "Ken" == Ken Raeburn <address@hidden> writes:
> 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....
Yes don't like it too much either, just a workaround as nobody is going
to fix the mmap() in the near future :) Plus I just witnessed GNU Octave
use 64MB of virtual memory on the 32MB RAM nanonote, so over-allocating
memomory seems to be a common disease nowadays.
>> $ 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.
The best solution will be to use strip instead of sstrip, and I think
the NanoNote firmware is going to use that very soon (since more sstrip
problems have been cropping up recently).
Going to post how that turns out.
cheers,
David
--
GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40
pgp7rN3ZFOTUC.pgp
Description: PGP signature