From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kuehling Newsgroups: gmane.emacs.devel Subject: Re: Some OpenWrt port related problems Date: Sun, 02 Jan 2011 22:12:30 +0100 Message-ID: <87sjxb9fi9.fsf@snail.Pool> References: <87sjxi5hko.fsf@snail.Pool> <87lj39y52n.fsf@snail.Pool> <87pqsl7wt7.fsf@snail.Pool> <66798668-5808-473B-BF11-DF4DBA5464A1@raeburn.org> <8739pc9039.fsf@snail.Pool> <83ei8wprid.fsf@gnu.org> <52B2D62A-17C0-4D11-9B48-8C9D0436807A@raeburn.org> <87pqsfcsyc.fsf@snail.Pool> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Trace: dough.gmane.org 1294003612 32263 80.91.229.12 (2 Jan 2011 21:26:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 2 Jan 2011 21:26:52 +0000 (UTC) Cc: Eli Zaretskii , rms@gnu.org, emacs-devel@gnu.org To: Ken Raeburn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 02 22:26:47 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PZVRu-00043e-Cr for ged-emacs-devel@m.gmane.org; Sun, 02 Jan 2011 22:26:46 +0100 Original-Received: from localhost ([127.0.0.1]:33469 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PZVEK-0006aH-7o for ged-emacs-devel@m.gmane.org; Sun, 02 Jan 2011 16:12:44 -0500 Original-Received: from [140.186.70.92] (port=60631 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PZVED-0006Wf-Ry for emacs-devel@gnu.org; Sun, 02 Jan 2011 16:12:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PZVEA-0002xb-Od for emacs-devel@gnu.org; Sun, 02 Jan 2011 16:12:37 -0500 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:39363 helo=mail.gmx.net) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1PZVEA-0002wp-D4 for emacs-devel@gnu.org; Sun, 02 Jan 2011 16:12:34 -0500 Original-Received: (qmail invoked by alias); 02 Jan 2011 21:12:32 -0000 Original-Received: from g225088181.adsl.alicedsl.de (EHLO snail.gmx.de) [92.225.88.181] by mail.gmx.net (mp062) with SMTP; 02 Jan 2011 22:12:32 +0100 X-Authenticated: #4121607 X-Provags-ID: V01U2FsdGVkX1+QGD8+H8eQvLFurtAEy+FCxI2CTojz1tZPkWANxV HHB5xebjaoJHot In-Reply-To: (Ken Raeburn's message of "Sun, 2 Jan 2011 15:35:27 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:134174 Archived-At: --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Ken" =3D=3D 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. >>=20 >> 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 >>=20 >> There are no sections in this file. >>=20 >> :) >>=20 >> 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 =2D-=20 GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFNIOo+fe9TI8F0fUARAtiEAJ9YNx/k+roUyRGVtxPLA7AQkxNsAACeO5DK ZW3UfMyJds2l1S0zsiS6EQI= =uypz -----END PGP SIGNATURE----- --=-=-=--