From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: Some OpenWrt port related problems Date: Sun, 2 Jan 2011 15:35:27 -0500 Message-ID: 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 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1294000551 19256 80.91.229.12 (2 Jan 2011 20:35:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 2 Jan 2011 20:35:51 +0000 (UTC) Cc: Eli Zaretskii , rms@gnu.org, emacs-devel@gnu.org To: David Kuehling Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 02 21:35:46 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 1PZUeV-0001Sk-Sj for ged-emacs-devel@m.gmane.org; Sun, 02 Jan 2011 21:35:44 +0100 Original-Received: from localhost ([127.0.0.1]:35399 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PZUeV-0000Q7-Cl for ged-emacs-devel@m.gmane.org; Sun, 02 Jan 2011 15:35:43 -0500 Original-Received: from [140.186.70.92] (port=59241 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PZUeP-0000Q2-RP for emacs-devel@gnu.org; Sun, 02 Jan 2011 15:35:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PZUeO-0002pI-LC for emacs-devel@gnu.org; Sun, 02 Jan 2011 15:35:37 -0500 Original-Received: from mail-qy0-f176.google.com ([209.85.216.176]:62769) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PZUeL-0002or-Fo; Sun, 02 Jan 2011 15:35:33 -0500 Original-Received: by qyk10 with SMTP id 10so13034638qyk.0 for ; Sun, 02 Jan 2011 12:35:32 -0800 (PST) Original-Received: by 10.229.100.20 with SMTP id w20mr17546613qcn.50.1294000529935; Sun, 02 Jan 2011 12:35:29 -0800 (PST) Original-Received: from squish.raeburn.org (c-24-128-190-224.hsd1.ma.comcast.net [24.128.190.224]) by mx.google.com with ESMTPS id t7sm10344171qcs.4.2011.01.02.12.35.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 02 Jan 2011 12:35:28 -0800 (PST) In-Reply-To: <87pqsfcsyc.fsf@snail.Pool> X-Mailer: Apple Mail (2.1082) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:134171 Archived-At: 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.... > $ readelf -t /usr/bin/emacs >=20 > There are no sections in this file. >=20 > :)=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. Ken=