bug#71292: 30.0.50; macOS: .elns have no debug info

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>>> Cc: 71292@debbugs.gnu.org
>>> Date: Fri, 31 May 2024 20:52:16 +0200
>>> 
>>> > Doesn't macOS support separate debug info, which can be created with
>>> > objcopy?  If it does, you could copy the debug info from the *.o
>>> > files, and then deleting them would not hamper debugging.
>>> 
>>> MacOS has .dSYM bundles, but how would you convince libgccjit/gcc to
>>> invoke dsymutil to produce them before it deletes the .o files? I don't
>>> see how that can be done.
>>
>> So let me be sure I understand: there's no was on macOS to produce a
>> shared library with debug info, except by keeping the *.o files
>> around?  IOW, when the linker produces a shared library, it doesn't
>> copy the debug info from the *.o files to the shared library, not even
>> given some optional command-line switch?
>
> That's correct.
>
> An executables on macOS cannot contain debug info as part of its own
> file. It contains only a "debug map" referencing the .o files from which
> it was built, and these contain the debug info.
>
> Alternatively, if the .o files are not present, or have changed, tools
> like debuggers can use .dSYM bundles which are produced by dsymutil from
> the .o files in an executable's debug map when it was built. It's acting
> like a sort of debug info linker in that case.

Just to mention it...

When debugging a native-compiled function (speed = 1) an macOS/arm64, I
find that the debug info that libgccjit 14.1 generates is apparently
incorrect.

For example, I see car_safe being called with some argument, but when I
look in the caller in the generated C file and print what it purportedly
passes as an argumebnt, it's something completely different.

That is of course pretty useless.