bug#47067: 28.0.50; [feature/native-comp] Crash while scrolling through dispnew.c

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: 47067@debbugs.gnu.org
>> Date: Sun, 21 Mar 2021 15:41:48 +0000
>> 
>> I was thinking, the only downside I see of this solution is that while
>> we can tweak the build system to signal to Emacs that a certain file
>> being compiled will be used for dump, this will indeed not be possible
>> for subsequent dumps.
>
> I don't think I follow: why would this be impossible for subsequent
> dumps?
>
> Maybe I should describe the use case this is supposed to solve.
> Imagine a repository where Emacs is being built regularly, and where
> old Emacs builds are kept for long periods of time, together with
> their *.pdmp files.  So we will have emacs-28.0.50.1, emacs-28.0.50.2,
> ... emacs-28-0.50.1000, ..., and their respective *.pdmp files.  The
> intent is to be able to run these old binaries for quick "bisecting"
> of issues reported by users.  This is what I do on my system: I keep
> one build from each of the previous months, and delete the rest.
>
> Until native-comp, keeping the binary and the .pdmp file was enough
> for being able to run that binary.  With native-comp, we also need the
> *.eln files that were dumped into each of the *.pdmp files.  I'm
> trying to find a reasonable solution to this problem.

Thanks I think I've understood the case.

I was referring to a different case, future dumps done by the user
calling directly `dump-emacs-portable', in that case some .eln might
stay where they were placed originally (not in the preloaded subfolder).

I know for now we don't support officially `dump-emacs-portable' to be
used directly by the user, so I'm not sure that's a real issue, but I
was trying to think future proof.

Thanks

  Andrea