From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ken Brown Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Sat, 17 Feb 2018 18:59:48 -0500 Message-ID: <0b25d5cc-1b3f-9e1b-afd8-d7d61a1788ff@cornell.edu> References: <321afd9b-15d6-e028-4aac-c646147883b4@cornell.edu> <810f778f-a3b3-2cb1-ccbe-36e5a29679ca@dancol.org> <3f85ba00-0ce7-1ea4-7d6f-12de8183cd17@cornell.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1518911929 8571 195.159.176.226 (17 Feb 2018 23:58:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 17 Feb 2018 23:58:49 +0000 (UTC) User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Cc: Eli Zaretskii , emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 18 00:58:44 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1enCNK-0001LU-0p for ged-emacs-devel@m.gmane.org; Sun, 18 Feb 2018 00:58:38 +0100 Original-Received: from localhost ([::1]:51769 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1enCPK-0008Q8-12 for ged-emacs-devel@m.gmane.org; Sat, 17 Feb 2018 19:00:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47727) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1enCOg-0008P7-5S for emacs-devel@gnu.org; Sat, 17 Feb 2018 19:00:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1enCOb-00034u-8Q for emacs-devel@gnu.org; Sat, 17 Feb 2018 19:00:02 -0500 Original-Received: from limerock03.mail.cornell.edu ([128.84.13.243]:44732) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1enCOb-00034X-3N; Sat, 17 Feb 2018 18:59:57 -0500 X-CornellRouted: This message has been Routed already. Original-Received: from authusersmtp.mail.cornell.edu (granite4.serverfarm.cornell.edu [10.16.197.9]) by limerock03.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id w1HNxmeJ031903; Sat, 17 Feb 2018 18:59:48 -0500 Original-Received: from [192.168.0.15] (mta-68-175-129-7.twcny.rr.com [68.175.129.7] (may be forged)) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id w1HNxkP0019537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 17 Feb 2018 18:59:47 -0500 In-Reply-To: <3f85ba00-0ce7-1ea4-7d6f-12de8183cd17@cornell.edu> Content-Language: en-US X-PMX-Cornell-Gauge: Gauge=XXXXX X-PMX-CORNELL-AUTH-RESULTS: dkim-out=none; X-MIME-Autoconverted: from 8bit to quoted-printable by limerock03.mail.cornell.edu id w1HNxmeJ031903 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 128.84.13.243 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:222868 Archived-At: On 2/17/2018 6:38 PM, Ken Brown wrote: > On 2/15/2018 9:36 PM, Daniel Colascione wrote: >> On 02/15/2018 05:56 PM, Ken Brown wrote: >>> On 2/15/2018 6:36 PM, Daniel Colascione wrote: >>>> On Feb 15, 2018 3:31 PM, Ken Brown wrote: > [...] >>>> =C2=A0=C2=A0=C2=A0 I just tried to build on 64-bit Cygwin, and the b= uild fails as=20 >>>> follows: >>>> >>>> =C2=A0=C2=A0=C2=A0 [...] >>>> =C2=A0=C2=A0=C2=A0 Dumping under the name bootstrap-emacs.pdmp >>>> =C2=A0=C2=A0=C2=A0 dumping fingerprint: >>>> =C2=A0=C2=A0=C2=A0 923050a9f611ad7ead76eea704308e4d05f152601a9134cf8= d1b5ff3e0e1a986 >>>> =C2=A0=C2=A0=C2=A0 Dump complete >>>> =C2=A0=C2=A0=C2=A0 Byte counts: header=3D80 hot=3D13187392 discardab= le=3D119424 cold=3D9086640 >>>> =C2=A0=C2=A0=C2=A0 Reloc counts: hot=3D919268 discardable=3D5790 >>>> =C2=A0=C2=A0=C2=A0 make -C ../lisp compile-first EMACS=3D"../src/boo= tstrap-emacs.exe" >>>> =C2=A0=C2=A0=C2=A0 make[2]: Entering directory >>>> =C2=A0=C2=A0=C2=A0 '/home/kbrown/src/emacs/x86_64-pdumper/lisp' >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 ELC=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 ../../pdumper/lisp/emacs-lisp/macroexp.elc >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 ELC=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 ../../pdumper/lisp/emacs-lisp/cconv.elc >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 ELC=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 ../../pdumper/lisp/emacs-lisp/byte-opt.elc >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 ELC=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 ../../pdumper/lisp/emacs-lisp/bytecomp.elc >>>> =C2=A0=C2=A0=C2=A0 emacs: could not load dump file "../src/bootstrap= -emacs.pdmp": out >>>> =C2=A0=C2=A0=C2=A0 of memory >>>> >>>> =C2=A0=C2=A0=C2=A0 There's probably some obvious explanation, but I = don't see it at=20 >>>> the >>>> =C2=A0=C2=A0=C2=A0 moment. >>>> >>>> >>>> I'm not entirely surprised to see Cygwin fall over here. We could=20 >>>> just use the Windows memory mapping functions directly, but I'd=20 >>>> prefer to stick with the POSIX API if we can make it work. >>> >>> I agree. >>> >>>> Any idea where in the mmap sequence we fail?=20 >>> >>> I haven't looked at the code yet, so I don't understand the question.= =20 >>> If you give me some guidance, I'll try to investigate. >> >> Thanks. I think the trouble must be in dump_mmap_contiguous. We report= =20 >> all errors from this function as "out of memory". dump_mmap_contiguous= =20 >> takes an array of mapping descriptors (think ELF segments or=20 >> something) and maps them all into a single contiguous region of=20 >> virtual memory. On POSIX systems, we reserve a chunk of address space=20 >> with a big PROT_NONE anonymous mapping, then carve it up into the=20 >> separate mappings that we really want. Windows doesn't support atomic=20 >> mmap replacement, so Cygwin has to emulate it, and I wouldn't be=20 >> surprised if something's going wrong in this emulation. >=20 > You're right that the problem is in dump_mmap_contiguous.=C2=A0 I stepp= ed=20 > through it in gdb and found the following: >=20 > 1. The call to dump_anonymous_allocate at pdumper.c:4432 succeeds. >=20 > 2. We enter the loop at pdumper.c:4451 with i =3D 0.=C2=A0 dump_map_fil= e is=20 > called, which calls dump_map_file_posix with protection =3D=20 > DUMP_MEMORY_ACCESS_READWRITE. >=20 > 3. This calls mmap at line 4219 with mem_prot =3D PROT_READ | PROT_WRIT= E=20 > and mem_flags =3D MAP_PRIVATE | MAP_FIXED. >=20 > 4. This mmap call fails. >=20 > I don't know if this is a bug in Cygwin's mmap or simply a limitation=20 > that has to be worked around.=C2=A0 Should I take this to the Cygwin ma= iling=20 > list, or do you have other ideas as to how to proceed? The following looks relevant: https://sourceware.org/ml/cygwin/2013-04/msg00372.html Ken