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

Previous Next

Full log

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

From: Mattias Engdegård <mattiase <at> acm.org>
To: Daniel Colascione <dancol <at> dancol.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 18:59:43 +0200

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

Is the cost of the all-sequential) paging-in noticeable? Surely a fair part of it will be required more or less immediately anyway.

The worst-case cost of an empty `-batch -Q` run actually decreased somewhat when forcing the dump to be read up front, although admittedly that was from a hot cache.

> 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.

Partial linking would help, unless we use a diabolic linker that rearranges the symbols based on the contents of a data array.

> 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.

No, I don't think that's a viable way. As you say, in-place modification wrecks havoc with any sort of binary checksumming.

Previous Next

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