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

[Eli Zaretskii]

> Date: Tue, 30 Mar 2021 10:50:05 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@debbugs.gnu.org
> 
> Here's what I did:
> 
>   . compiled the example with -gdwarf-4 -g3
>   . started GDB and ran the program until it calls the 'greet'
>     function
>   . used "si" and "ni" commands to step into 'greet' and through the
>     functions it calls

I have now compiled a slightly modified version of the hello world
example, after adding this to the source:

  gcc_jit_context_set_bool_option (
                                   ctxt,
                                   GCC_JIT_BOOL_OPTION_DEBUGINFO,
                                   1);

The results under debugger are slightly better, for example, the
arguments to JIT functions are shown:

  (gdb) bt
  #0  0x6ac81280 in greet (name=0x406088 "world")
     from C:\DOCUME~1\Zaretzky\LOCALS~1\Temp\libgccjit-0z6iua\fake.so

However, the "??" thingies and the incomplete backtraces are still
present, here are two examples:

  #0  0x77c418ab in printf () from C:\WINDOWS\system32\msvcrt.dll
  #1  0x00000001 in ?? ()
  #2  0x77c5fca0 in msvcrt!_iob () from C:\WINDOWS\system32\msvcrt.dll
  #3  0x77c5fca0 in msvcrt!_iob () from C:\WINDOWS\system32\msvcrt.dll
  #4  0x6ac83044 in ?? ()
     from C:\DOCUME~1\Zaretzky\LOCALS~1\Temp\libgccjit-0z6iua\fake.so
  #5  0x6ac81299 in greet (name=0x406088 "world")
     from C:\DOCUME~1\Zaretzky\LOCALS~1\Temp\libgccjit-0z6iua\fake.so
  #6  0x004016f5 in main (argc=1, argv=0x3e2978) at tut01d-hello-world.c:121

  #0  0x77c41883 in printf () from C:\WINDOWS\system32\msvcrt.dll
  #1  0x00000001 in ?? ()
  #2  0x77c5fca0 in msvcrt!_iob () from C:\WINDOWS\system32\msvcrt.dll
  #3  0x00000000 in ?? ()

This is quite disappointing.  It probably means that debugging Emacs
with natively-compiled Lisp will be much harder on MS-Windows, if you
happen to be in a situation (whose causes are still unclear to me,
probably some minor variations of the prologue code?) with these
incomplete backtraces.

I also have 3 followup questions:

 1) When GCC_JIT_BOOL_OPTION_DEBUGINFO is used, what kind of debug
    info is generated by libgccjit? is it DWARF2 or stabs or something
    else?  Using "objdump -W", it looks like DWARF2, but if so, why
    isn't GDB able to produce a decent backtrace?

 2) If the debug info created under GCC_JIT_BOOL_OPTION_DEBUGINFO is
    not DWARF2, is it possible to use
    gcc_jit_context_add_command_line_option to request "-gdwarf-4" or
    similar, like we do with the command-line GCC, so that the debug
    info for the JIT code is more detailed and accurate?

 3) I see in my temporary directory subdirectories, created when I run
    the example program, with files fake.s and fake.so.  Are they
    supposed to be left there, or are they supposed to be deleted
    when the program exits?

Thanks.