[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#34180: 27.0.50; argv[0] used incorrectly to find the .pdmp
From: |
Mattias Engdegård |
Subject: |
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.
bug#34180: 27.0.50; argv[0] used incorrectly to find the .pdmp, Eli Zaretskii, 2021/10/11
bug#34180: 27.0.50; argv[0] used incorrectly to find the .pdmp, Richard Stallman, 2021/10/11
bug#34180: 27.0.50; argv[0] used incorrectly to find the .pdmp, Mattias Engdegård, 2021/10/12