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: Sat, 1 Jan 2011 20:35:45 -0500 Message-ID: <52B2D62A-17C0-4D11-9B48-8C9D0436807A@raeburn.org> 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> 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 1293932166 23811 80.91.229.12 (2 Jan 2011 01:36:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 2 Jan 2011 01:36:06 +0000 (UTC) Cc: David Kuehling , rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 02 02:36:01 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 1PZCrX-0007SC-Et for ged-emacs-devel@m.gmane.org; Sun, 02 Jan 2011 02:36:00 +0100 Original-Received: from localhost ([127.0.0.1]:41215 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PZCrW-0005HC-Mv for ged-emacs-devel@m.gmane.org; Sat, 01 Jan 2011 20:35:58 -0500 Original-Received: from [140.186.70.92] (port=54098 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PZCrS-0005H6-5U for emacs-devel@gnu.org; Sat, 01 Jan 2011 20:35:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PZCrR-0002LT-0r for emacs-devel@gnu.org; Sat, 01 Jan 2011 20:35:54 -0500 Original-Received: from mail-qw0-f41.google.com ([209.85.216.41]:37212) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PZCrN-0002Kv-Uv; Sat, 01 Jan 2011 20:35:50 -0500 Original-Received: by qwa26 with SMTP id 26so12347913qwa.0 for ; Sat, 01 Jan 2011 17:35:48 -0800 (PST) Original-Received: by 10.229.227.8 with SMTP id iy8mr16602944qcb.182.1293932148506; Sat, 01 Jan 2011 17:35:48 -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 g32sm11006740qck.22.2011.01.01.17.35.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 01 Jan 2011 17:35:46 -0800 (PST) In-Reply-To: <83ei8wprid.fsf@gnu.org> 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:134140 Archived-At: On Jan 1, 2011, at 10:34, Eli Zaretskii wrote: >> From: David Kuehling >> Date: Sat, 01 Jan 2011 15:20:58 +0100 >> Cc: rms@gnu.org, Emacs Dev >> Finding pointers to doc strings...done >> emacs: Can't allocate buffer for /usr/bin/emacs >>=20 >> So it wants to pull a full copy of the emacs binary into memory? >=20 > It tries to mmap it, yes: Contrary to the comment in unexelf.c saying "We do not use mmap because = that fails with NFS." :-) Perhaps we could reduce the memory requirement a bit by (in the ELF = case) mapping the ELF header and read-only sections as shared, read-only = data, so the process wouldn't need space from the OS for private = modifications to those pages. It would take a bit more work to do that, = though. (Strawman design: Map the whole file read-only and shared. = Parse the program headers and build a list of file-offset ranges that = need write access. Then map private copies of the necessary pages of = the original file in over the read-only ones.) Or perhaps some of the = read-write regions could just be written out from the running process, = ignoring the on-disk version; I haven't looked at how unexelf.c works = very closely. If enabling overcommit or swapping temporarily on the few systems where = Emacs can't build gets us around the problem, I'm not sure if it's worth = it, but if some OpenWrt hacker wants to experiment with it, I don't = think it would be a bad change. >> Finding pointers to doc strings...done >> emacs: Program segment above .bss in /usr/bin/emacs >>=20 >> So what's that supposed to mean? >=20 > This message comes from this portion of unexelf.c: >=20 > /* Fix up a new program header. Extend the writable data segment so > that the bss area is covered too. Find that segment by looking > for a segment that ends just before the .bss area. Make sure > that no segments are above the new .data2. Put a loop at the end > to adjust the offset and address of any segment that is above > data2, just in case we decide to allow this later. */ >=20 > for (n =3D new_file_h->e_phnum - 1; n >=3D 0; n--) > { > /* Compute maximum of all requirements for alignment of section. = */ > ElfW(Word) alignment =3D (NEW_PROGRAM_H (n)).p_align; > if ((OLD_SECTION_H (old_bss_index)).sh_addralign > alignment) > alignment =3D OLD_SECTION_H (old_bss_index).sh_addralign; >=20 > #ifdef __sgi > /* According to r02kar@x4u2.desy.de (Karsten Kuenne) > and oliva@gnu.org (Alexandre Oliva), on IRIX 5.2, we > always get "Program segment above .bss" when dumping > when the executable doesn't have an sbss section. */ > if (old_sbss_index !=3D -1) > #endif /* __sgi */ > if (NEW_PROGRAM_H (n).p_vaddr + NEW_PROGRAM_H (n).p_filesz > > (old_sbss_index =3D=3D -1 > ? old_bss_addr > : round_up (old_bss_addr, alignment))) > fatal ("Program segment above .bss in %s\n", old_name, 0); >=20 > I don't know enough about unexelf, nor about ELF in general, to tell > what this means or what to do about this, though. Anyone? It appears to be looking for any higher-numbered segment in the old = executable (despite the NEW_* macros, printf shows the numbers as being = those from temacs) which ends at an address higher than where the BSS = section started; it quits the loop when finding a normal (PT_LOAD) = segment where the on-disk data ends on the page where the BSS section = starts. The latter is to find the segment where our former BSS storage = gets added as initialized data. It certainly makes sense to me that we don't want to find the BSS start = within initialized data or other mapped-in segments; that would be = inconsistent. In fact, the whole region of former-BSS and dynamically = allocated storage that we want to turn into initialized data shouldn't = overlap with pre-existing initialized data or other mapped-in segments. = But why we don't check for the segment start addresses, or why the = segment numbering matters, I'm not sure. (Most of my experience with = ELF format was in reading and writing object files, where the sections = are all that matters and segments aren't defined, and I didn't deal with = MIPS much. And I'm dredging up decade-plus-old memories for this, so = I'm a bit rusty.) I assume there's some (official or de facto) standard = to the segment ordering involved here. Nor is it clear to me why simply = shutting off the check, instead of adjusting it, is the right thing for = executables with .sbss sections on SGI systems specifically. I did a MIPS32 (Lemote laptop) GNU/Linux build of the latest alpha = snapshot; no error was produced. According to "readelf -e", temacs has = no .sbss section. The on-disk part of segment 4 does end at the start = of BSS, and it's the segment with the highest memory address (not file = offset) overall, so there's nothing mapped higher than the BSS. So I'm = afraid I can't help much, at least without more info (e.g., "readelf -e = temacs", to see how it's different from mine). And I'm not sure I know = enough about the linker view on MIPS to help anyways. Ken=