https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59075
Eric Gallager <egallager at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |egallager at gcc dot gnu.org
--- Comment #12 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #11)
> (In reply to Jonathan Wakely from comment #10)
> > Tom, do you know why the types might be shown differently on OS X and
> > GNU/Linux? (see comments 7 and 8).
> >
> > Is that because of something different in the DWARF? Is that expected for OS
> > X, or is it a GCC bug?
>
> Can we check that this is still current on trunk after the fix for 70694 was
> applied - since that alters visibility of some symbols (maybe a long shot).
>
> It's not expected that Darwin will do anything differently modulo (1) it
> doesn't use .cfi_xxx at present, (2) it's generally limited to DWARF2 [a
> historical issue with older versions of dsymutil, see below], although I
> hope to lift that restriction soon, since we now have a DWARF4-capable
> dsymutil
>
> However ...... the status quo is:
>
> Darwin has the following strategy for debug.
> 1. the static linker ignores DWARF but writes a table of object file
> locations into the executable.
> 2a. the executable + the object files can be consumed by a debug client
> (e.g. GDB)
> - the table in the exe tells the client where to find the objects and it
> can read/link the DWARF from them directly. This often makes sense for a
> developer who is doing a lot of compile/edit/debug loops. GDB understands
> this approach (last i tried),
>
> 2b. if one doesn't want to keep the objects around; the executable + the
> objects can be consumed by "dsymutil" this is Darwin's debug linker, which
> produces a monolithic debug object (which can be consumed alongside the
> actual executable to provide the debug data). For whatever reason, the
> design wraps this linked debug object in a macOS package structure thus:
> <exename>.dSYM/
> Contents/
> Resources/
> DWARF/
> exename
>
> This applies to any DSO, so shlibs are the same (for libstdc++ the 'exename'
> would be libstdc++.dlib).
>
> - I'm not 100% sure whether upstream GDB still (or ever did) understands
> the packaged version, Apple's GDB did - but that's long out of date.
I tried merging upstream GDB and Apple's GDB once, but got distracted by yak
shaving and eventually ended up breaking things worse than when I had
started... if you want to try picking up where I left off with merging them,
though, my repo is here: https://github.com/cooljeanius/apple-gdb-1824
For this particular issue, of gdb understanding the packaged version of the
debug objects, check macosx-tdep.c:
https://github.com/cooljeanius/apple-gdb-1824/blob/master/src/gdb/macosx/macosx-tdep.c
And also macosx-bundle-utils.c:
https://github.com/cooljeanius/apple-gdb-1824/blob/master/src/gdb/macosx/macosx-bundle-utils.c
>
> ==
>
> As for reading Mach-O DWARF, binutils works for x86_64-apple-darwin last I
> tried (you have to point it at the actual linked DWARF tho, I don't think
> any of the tools understand the .dSYM package layout).
>
> Alternately, the llvm binutils look-alikes are getting more compatible and
> consume Mach-O.
>
> Caveat, I've, but not built/tested binutils / GDB for at least 6 months on
> Darwin, so my comments might be out of date.
