bug#63365: 30.0.50; GCC 13.1 breaks building Emacs with native-compilation

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 11 May 2023 13:06:15 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 63365@debbugs.gnu.org, akrl@sdf.org
> 
> > Cc: 63365@debbugs.gnu.org, akrl@sdf.org
> > Date: Wed, 10 May 2023 22:08:57 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > 
> > > Cc: 63365@debbugs.gnu.org, akrl@sdf.org
> > > Date: Wed, 10 May 2023 19:54:06 +0300
> > > From: Eli Zaretskii <eliz@gnu.org>
> > > 
> > > Maybe it's a bug in your addr2line, then.  It works perfectly here,
> > > FWIW.
> > > 
> > > Can you make the unstripped emacs.exe available for download
> > > somewhere, along with the emacs_backtrace.txt produced by that same
> > > binary?  I'd like to take a look.
> > 
> > Hmm... looking at the files you sent, I'm beginning to think something
> > is wrong with generating backtraces on MS-Windows in the 64-bit
> > builds.  Maybe it has to do with ASLR, or maybe the code which
> > produces the backtrace is wrong in 64-bit executables.
> 
> Actually, I take this back: the addresses in emacs_backtrace.txt seem
> reasonable, similar to addresses shown in GDB backtraces from a 64-bit
> Windows build we have on the bug tracker.
> 
> So the suspicion goes back to addr2line, although I see the same
> problem with my version, which I built myself and which works
> flawlessly with the 32-bit MinGW build of Emacs.

This conclusion was incorrect.  There's nothing wrong with addr2line;
the reason for the problem _was_ ASLR.  addr2line interprets the
addresses in emacs_backtrace.txt relative to the base address of the
program image as recorded in the PE header of the executable file.  It
cannot do anything else, since it doesn't have a live program to work
with (unlike when running Emacs under GDB).  But ASLR causes programs
be loaded at base addresses that are randomized from run to run, and
thus are usually different from what is recorded in the PE header.  So
for this to work on modern versions of Windows, Emacs must correct the
addresses it writes to emacs_backtrace.txt, so as to make them match
the situation where Emacs is loaded at the fixed base address recorded
in the header.

I recently upgraded my main development machine, and, as luck would
have it, had crashes during the build, so I could study the problem
and fix it.  It should now be fixed on the master branch.  I could
only test the solution in a 32-bit MinGW build, so please try testing
it in the 64-bit build when you have a crash on your hands.

Thanks.