From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Andy Moreton Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Fri, 16 Feb 2018 11:33:35 +0000 Message-ID: References: <1775923222.898447.1518559575706@mail.libero.it> <83inb0xkfx.fsf@gnu.org> <87o9krdftc.fsf@gmail.com> <83a7wby1x4.fsf@gnu.org> <83r2pnwftj.fsf@gnu.org> <08ac43fb-0b13-8a51-4571-11a21b8ffbdc@dancol.org> <83h8qiw7cd.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1518781009 11069 195.159.176.226 (16 Feb 2018 11:36:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Feb 2018 11:36:49 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.91 (windows-nt) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 16 12:36:45 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 1emeJY-0001eg-Lg for ged-emacs-devel@m.gmane.org; Fri, 16 Feb 2018 12:36:28 +0100 Original-Received: from localhost ([::1]:39056 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1emeLa-0002hM-P0 for ged-emacs-devel@m.gmane.org; Fri, 16 Feb 2018 06:38:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60461) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1emeKd-0002cX-PG for emacs-devel@gnu.org; Fri, 16 Feb 2018 06:37:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1emeKY-0001s5-Sx for emacs-devel@gnu.org; Fri, 16 Feb 2018 06:37:34 -0500 Original-Received: from [195.159.176.226] (port=55775 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1emeKY-0001rp-LX for emacs-devel@gnu.org; Fri, 16 Feb 2018 06:37:30 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1emeIE-000519-DR for emacs-devel@gnu.org; Fri, 16 Feb 2018 12:35:06 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 66 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:vktdFIrwYKdozfACQgBI4XEZnlU= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:222811 Archived-At: On Thu 15 Feb 2018, Eli Zaretskii wrote: >> Cc: rpluim@gmail.com, emacs-devel@gnu.org >> From: Daniel Colascione >> Date: Wed, 14 Feb 2018 11:26:37 -0800 >> >> >> It's weird that we're failing there. If we're looking at a buffer with >> >> dumped contents, we set b->text->beg to NULL, then use the normal >> >> buffer-allocation procedure (whichever we're compiled to use) to >> >> allocate memory for the contents. How can the resulting address ever be >> >> equal to what we started with? Neither mmap_realloc nor r_re_alloc nor >> >> xrealloc should ever reuse the address. >> > >> > You are talking about what enlarge_buffer_text does? IOW, this: >> >> It should be fixed now. Give it a shot. > > Thanks, the problem is indeed fixed, and with that I was able to > successfully complete the bootstrap. > > I also tested an optimized build, and a parallel "make -j8" build, and > they all worked as expected. > > The times to load the .pdmp file are around 20 msec for an unoptimized > build and 7 msec for an optimized build, which I think is very > impressive. > > For the record, this is a 32-bit MinGW build configured with > "--with-large-int --with-modules --enable-checking", on a 3-year old > Core i7 box running Windows 7. It fails to build for 64bit Windows with Mingw64 on msys2: C:/emacs/git/emacs/pdumper/src/pdumper.c: In function 'dump_read_all': C:/emacs/git/emacs/pdumper/src/pdumper.c:4784:45: error: conversion to 'unsigned int' from 'size_t {aka long long unsigned int}' may alter its value [-Werror=conversion] read (fd, (char*) buf + bytes_read, bytes_to_read - bytes_read); ^~~~~~~~~~~~~ In file included from C:/emacs/git/emacs/pdumper/src/character.h:27:0, from C:/emacs/git/emacs/pdumper/src/buffer.h:27, from C:/emacs/git/emacs/pdumper/src/pdumper.c:18: C:/emacs/git/emacs/pdumper/src/pdumper.c: In function 'dump_object_1': C:/emacs/git/emacs/pdumper/src/lisp.h:206:5: warning: this statement may fall through [-Wimplicit-fallthrough=] (suppress_checking || (cond) \ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ? (void) 0 \ ~~~~~~~~~~~~~~~~~~ : die (# cond, __FILE__, __LINE__)) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C:/emacs/git/emacs/pdumper/src/pdumper.c:2915:11: note: in expansion of macro 'eassert' eassert ("should not be dumping int: is self-representing" && 0); ^~~~~~~ C:/emacs/git/emacs/pdumper/src/pdumper.c:2916:9: note: here default: ^~~~~~~ cc1.exe: some warnings being treated as errors This appears to be because sys_read() and _read() take an unsigned int for count rather than size_t. Changing the code to: read (fd, (char*) buf + bytes_read, (int)(bytes_to_read - bytes_read)); That builds and appears to run, but it would be nicer to get sys_read etc. to use the proper types. AndyM