public inbox for jit@gcc.gnu.org
 help / color / mirror / Atom feed
* Debug info on macOS
@ 2024-05-10 13:46 Gerd Möllmann
  2024-05-10 20:17 ` David Malcolm
  0 siblings, 1 reply; 4+ messages in thread
From: Gerd Möllmann @ 2024-05-10 13:46 UTC (permalink / raw)
  To: jit

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!


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Debug info on macOS
  2024-05-10 13:46 Debug info on macOS Gerd Möllmann
@ 2024-05-10 20:17 ` David Malcolm
  2024-05-10 22:11   ` Andrea Corallo
  2024-05-11  3:39   ` Gerd Möllmann
  0 siblings, 2 replies; 4+ messages in thread
From: David Malcolm @ 2024-05-10 20:17 UTC (permalink / raw)
  To: Gerd Möllmann, jit; +Cc: Andrea Corallo

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Debug info on macOS
  2024-05-10 20:17 ` David Malcolm
@ 2024-05-10 22:11   ` Andrea Corallo
  2024-05-11  3:39   ` Gerd Möllmann
  1 sibling, 0 replies; 4+ messages in thread
From: Andrea Corallo @ 2024-05-10 22:11 UTC (permalink / raw)
  To: David Malcolm, Gerd Möllmann, jit; +Cc: acorallo, nd

________________________________________
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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Debug info on macOS
  2024-05-10 20:17 ` David Malcolm
  2024-05-10 22:11   ` Andrea Corallo
@ 2024-05-11  3:39   ` Gerd Möllmann
  1 sibling, 0 replies; 4+ messages in thread
From: Gerd Möllmann @ 2024-05-11  3:39 UTC (permalink / raw)
  To: David Malcolm; +Cc: jit, Andrea Corallo

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!

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2024-05-11  3:39 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-05-10 13:46 Debug info on macOS Gerd Möllmann
2024-05-10 20:17 ` David Malcolm
2024-05-10 22:11   ` Andrea Corallo
2024-05-11  3:39   ` Gerd Möllmann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).