GNU bug report logs - #71292
30.0.50; macOS: .elns have no debug info

Previous Next

Full log

Message #29 received at 71292 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71292 <at> debbugs.gnu.org
Subject: Re: bug#71292: 30.0.50; macOS: .elns have no debug info
Date: Fri, 31 May 2024 21:22:21 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: 71292 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.