bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int

[Eli Zaretskii <eliz@gnu.org>]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: andrewjmoreton@gmail.com, 46495@debbugs.gnu.org
> Date: Mon, 29 Mar 2021 16:15:56 +0000
> 
> >   https://sourceware.org/pipermail/gdb-patches/2021-March/177334.html
> >
> > Is that possible?
> 
> Well if this is what you observe it certainly can be.  There might very
> well be something in how/what libgccjit generates that is causing this
> difference.

David, can you please chime in and help us understand what is going on
here?

> > are we doing something that could affect the
> > prologue of the natively-compiled Lisp code?
> 
> I suspect this is a libgccjit thing, without knowing where the
> difference is coming from it's hard to predict if there's a workaround
> we can put in place in the Emacs codebase, but I suspect there's not.
> 
> If the generated code is correct I think gdb should recognize it
> improving its unwinder, otherwise if this is a libgccjit bug we should
> open a PR on bugzilla.

GDB's native platform is ELF-based, so its unwinders' support for
COFF-PE format used by MS-Windows is known to be less thorough.

> Perhaps if the case is the later one can try a simpler testcase to
> report it using the test we have in the configure or libgccjit hello
> world [1].  This might help also analysing how this different frame is
> formed.

I think if David doesn't show us the light, my best bet is to
recompile the Lisp code with debug info and see if that resolves the
problem and/or allows us to understand why the code with no debug info
produces these effects.

Thanks.