Debug info on macOS

Debug info on macOS

[Gerd Möllmann]

Hi,

I'm developing Emacs using its native compilation on macOS, which is
based on libgccjit.

In this context, I'm currently failing to get .eln files (= .so, .dylib,
.dll depending on the platform) with debug info. This has probably its
roots in the special handling of DWARF under macOS, a long-winded story
leading to dSYM bundles...

My question is: can I somehow configure libgccjit in a way that keeps
the .o file that was used to produce the resulting .dylib, like it
keeps/writes the various intermediate files that one can get?

If that's possible, my hope would be to extract the debug info from the
.o using dsymutil and use that with the .dylib.

TIA!

Re: Debug info on macOS

[David Malcolm]

On Fri, 2024-05-10 at 15:46 +0200, Gerd Möllmann wrote:
> Hi,
> 
> I'm developing Emacs using its native compilation on macOS, which is
> based on libgccjit.
> 
> In this context, I'm currently failing to get .eln files (= .so,
> .dylib,
> .dll depending on the platform) with debug info. This has probably
> its
> roots in the special handling of DWARF under macOS, a long-winded
> story
> leading to dSYM bundles...
> 
> My question is: can I somehow configure libgccjit in a way that keeps
> the .o file that was used to produce the resulting .dylib, like it
> keeps/writes the various intermediate files that one can get?
> 
> If that's possible, my hope would be to extract the debug info from
> the
> .o using dsymutil and use that with the .dylib.

[CCing Andrea Corallo for his Emacs expertise]

I confess I've not done any compilation on macOS and am not familiar
with the tools, formats and "special handling of DWARF under macOS" you
mention.

As I understand it, Emacs is using libgccjit to do ahead-of-time
compilation, presumably compiling the optimized ELisp code to machine
code as a shared library.

Is Emacs using gcc_jit_context_compile_to_file with
GCC_JIT_OUTPUT_KIND_DYNAMIC_LIBRARY, or is it doing something more
complicated?

If that's what it's doing, you might want to take a look
at playback::context::compile in gcc/jit-playback.cc (and try stepping
through it in the debugger).  In particular, the
playback::compile_to_file::postprocess implementation of the
playback::context::postprocess vfunc is responsible for taking a .s in
a tempdir and turning it into the desired output.  Perhaps there's some
macOS-specific special-casing needed there?

You might also find it useful to look at the overview of how
libgccjit's internals here:
https://gcc.gnu.org/onlinedocs/jit/internals/index.html#overview-of-code-structure

Hope this is helpful
Dave

Re: Debug info on macOS

[Andrea Corallo]

________________________________________
From: David Malcolm <dmalcolm@redhat.com>
Sent: Friday, May 10, 2024 10:17 PM
To: Gerd Möllmann <gerd.moellmann@gmail.com>; jit@gcc.gnu.org <jit@gcc.gnu.org>
Cc: Andrea Corallo <Andrea.Corallo@arm.com>
Subject: Re: Debug info on macOS
 
[...]

> As I understand it, Emacs is using libgccjit to do ahead-of-time
> compilation, presumably compiling the optimized ELisp code to machine
> code as a shared library.

That's correct (we do also jit compilation but I think is not relevant
here).

> Is Emacs using gcc_jit_context_compile_to_file with
> GCC_JIT_OUTPUT_KIND_DYNAMIC_LIBRARY, or is it doing something more
> complicated?

We use GCC_JIT_OUTPUT_KIND_DYNAMIC_LIBRARY.

Thanks!

  Andrea

Re: Debug info on macOS

[Gerd Möllmann]

David Malcolm <dmalcolm@redhat.com> writes:

> As I understand it, Emacs is using libgccjit to do ahead-of-time
> compilation, presumably compiling the optimized ELisp code to machine
> code as a shared library.

Correct.

> Is Emacs using gcc_jit_context_compile_to_file with
> GCC_JIT_OUTPUT_KIND_DYNAMIC_LIBRARY, or is it doing something more
> complicated?

Yes. (Sorry, I forgot to CC Andrea; he sent me here :-)).

> If that's what it's doing, you might want to take a look
> at playback::context::compile in gcc/jit-playback.cc (and try stepping
> through it in the debugger).  In particular, the
> playback::compile_to_file::postprocess implementation of the
> playback::context::postprocess vfunc is responsible for taking a .s in
> a tempdir and turning it into the desired output.  Perhaps there's some
> macOS-specific special-casing needed there?
>
> You might also find it useful to look at the overview of how
> libgccjit's internals here:
> https://gcc.gnu.org/onlinedocs/jit/internals/index.html#overview-of-code-structure
>
> Hope this is helpful

Yes it is. Thanks, David!

Re: Debug info on macOS

[Gerd Möllmann]

On 2024-05-11 05:39, Gerd Möllmann wrote:
> David Malcolm <dmalcolm@redhat.com> writes:
> 
>> As I understand it, Emacs is using libgccjit to do ahead-of-time
>> compilation, presumably compiling the optimized ELisp code to machine
>> code as a shared library.
> 
> Correct.
> 
>> Is Emacs using gcc_jit_context_compile_to_file with
>> GCC_JIT_OUTPUT_KIND_DYNAMIC_LIBRARY, or is it doing something more
>> complicated?
> 
> Yes. (Sorry, I forgot to CC Andrea; he sent me here :-)).
> 
>> If that's what it's doing, you might want to take a look
>> at playback::context::compile in gcc/jit-playback.cc (and try stepping
>> through it in the debugger).  In particular, the
>> playback::compile_to_file::postprocess implementation of the
>> playback::context::postprocess vfunc is responsible for taking a .s in
>> a tempdir and turning it into the desired output.  Perhaps there's some
>> macOS-specific special-casing needed there?
>>
>> You might also find it useful to look at the overview of how
>> libgccjit's internals here:
>> https://gcc.gnu.org/onlinedocs/jit/internals/index.html#overview-of-code-structure
>>
>> Hope this is helpful
> 
> Yes it is. Thanks, David!

Found something out.

Passing -save-temps=obj to libgccjit makes it keep the .o file used to 
compile the .eln dylibs in Emacs/macOS. Libgccjit then performs the same 
way gcc-14 does on macOS when compiling with -g.

Maybe one could check what gcc-14 does for -g on macOS, and do the same 
when libgccjit compiles with debug > 0. I'm not familiar enough with GCC 
to do that in a reasoanble time, sorry. And I can't build it easily.