bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Malcolm
Subject: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int
Date: Mon, 29 Mar 2021 14:11:28 -0400
User-agent: Evolution 3.38.3 (3.38.3-1.fc33)

On Mon, 2021-03-29 at 19:59 +0300, Eli Zaretskii wrote:
> > 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?

In theory, libgccjit uses the same code-generation code and the same
debuginfo-generation code as a regular gcc invocation.

Some ideas:

(a) Is libgccjit being invoked multiple times in-process?
If so, I wonder if you're running into a latent bug in state-handling
in libgccjit that's affecting either code generation or debuginfo
generation.  Maybe something isn't being reset that should have been?

Is there a way to get emacs to only do one libgccjit context
compilation per process, and see if that affects things?

(b) Alternatively, maybe a simple bug in libgccjit that affects the
first in-process invocation?

(c) Alternatively, maybe a bug in the emacs jit stuff that's corrupting
the stack somehow?

Some debugging hooks are here:
  https://gcc.gnu.org/onlinedocs/jit/topics/contexts.html#debugging


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

In particular, this may be helpful for that:
https://gcc.gnu.org/onlinedocs/jit/topics/contexts.html#c.gcc_jit_context_dump_reproducer_to_file


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

I'd try turning on debuginfo generation to see if that helps.

Hope this is helpful
Dave







reply via email to

[Prev in Thread] Current Thread [Next in Thread]