GNU bug report logs - #34180
27.0.50; argv[0] used incorrectly to find the .pdmp

Previous Next

Full log

Message #66 received at 34180 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 34180 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 Paul Eggert <eggert <at> cs.ucla.edu>, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#34180: 27.0.50; argv[0] used incorrectly to find the .pdmp
Date: Tue, 12 Oct 2021 09:24:48 -0700

On 10/12/21 5:27 AM, Mattias Engdegård wrote:
> I don't think Paul meant that we necessarily have to use the embedded dump in-place. It could just as well be the source of a memory copy to its runtime location; everything would then work just like today except that the dump file is embedded into the executable.

Copying the dump on startup will hurt performance --- the dump is meant 
to be used directly from a disk-backed file.

I'm also not entirely clear on how you're planning on avoiding the usual 
problems with executable modification --- relinking the executable can 
change all the locations of the symbols in the binary, and if symbol 
locations change, any previously-generated dump becomes invalid.

Even if on *some* platforms *today* we can replace an embedded dump 
image in an already-built executable without re-linking the thing, 
there's no guarantee that we can continue doing that. (For example --- 
imagine a future platform that signs all binaries during the build 
process.) Modifying binaries is always a platform-specific thing and 
doing it for Emacs risks forward compatibility. Usin a separate dump 
file relies only on public APIs guaranteed to work forever.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.