>>>>> "Ken" == Ken Raeburn 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