[Bug libstdc++/59075] python pretty printer does not work at OS X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59075 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #12 from Eric Gallager --- (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: > .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.
[Bug libstdc++/59075] python pretty printer does not work at OS X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59075 --- Comment #11 from Iain Sandoe --- (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: .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. == 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.
[Bug libstdc++/59075] python pretty printer does not work at OS X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59075 Jonathan Wakely changed: What|Removed |Added Severity|trivial |normal
[Bug libstdc++/59075] python pretty printer does not work at OS X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59075 --- Comment #10 from Jonathan Wakely --- 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?
[Bug libstdc++/59075] python pretty printer does not work at OS X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59075
--- Comment #9 from manuelrciosici at gmail dot com ---
Just to be sure this ticket doesn't get considered out of date, I want to
confirm that this is still an issue on OS X 10.12.3 using GCC 6.3 (compiled
from Homebrew) and GDB 7.12.1 (compiled from Homebrew). Alexander Timin's
suggestion still fixes issues for some collections like vector, but not for
others like unordered sets or other structures like strings.
(In reply to Jonathan Wakely from comment #8)
> Odd, on GNU/Linux I get:
>
> type = class std::vector > :
> protected std::_Vector_base > {
>
>
> i.e. it has std:: qualification, and doesn't have the [with _Tp = ...] stuff
> which G++ outputs in diagnostics, but doesn't belong in the debug info if I
> understand correctly.
>
> Iain, I don't know how to read the DWARF in the attachments, do you? And do
> you know anything about why the DWARF info is different in this way?
[Bug libstdc++/59075] python pretty printer does not work at OS X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59075
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-04-12
CC||iains at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #8 from Jonathan Wakely ---
Odd, on GNU/Linux I get:
type = class std::vector > :
protected std::_Vector_base > {
i.e. it has std:: qualification, and doesn't have the [with _Tp = ...] stuff
which G++ outputs in diagnostics, but doesn't belong in the debug info if I
understand correctly.
Iain, I don't know how to read the DWARF in the attachments, do you? And do you
know anything about why the DWARF info is different in this way?
[Bug libstdc++/59075] python pretty printer does not work at OS X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59075 manuelrciosici at gmail dot com changed: What|Removed |Added CC||manuelrciosici at gmail dot com --- Comment #7 from manuelrciosici at gmail dot com --- I can confirm having the same issue on OS X 10.11.4 with GDB 7.8 (from CLion) and with GDB 7.11 (compiled from Homebrew). I am using GCC 5.3.0 also compiled from Homebrew. Alexander's code suggestion fixed the problem for me. When I call 'ptype' on a vector of unsigned long I get the following: type = class vector > [with _Tp = unsigned long, _Alloc = allocator] : protected _Vector_base<_Tp, std::_Alloc>
[Bug libstdc++/59075] python pretty printer does not work at OS X
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59075 --- Comment #2 from Tom Tromey tromey at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #1) Tom, do you know why this would be true on OS X? Offhand I do not know. I think there are a few things that could help us find out, though. One would be to see the gdb session. This would tell us which libstdc++ is being loaded. Another would be to attach the executable to the bug, assuming it is small enough (if too large -- write a minimal reproducer and attach it). Then I could look at the DWARF. I'm also curious exactly what options were used to build the executable. This can matter sometimes.
[Bug libstdc++/59075] python pretty printer does not work at OS X
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59075 --- Comment #3 from Alexander Timin altimin at altimin dot ru --- Created attachment 31195 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31195action=edit compiled dwarf file
[Bug libstdc++/59075] python pretty printer does not work at OS X
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59075 --- Comment #5 from Alexander Timin altimin at altimin dot ru --- Created attachment 31197 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31197action=edit source code
[Bug libstdc++/59075] python pretty printer does not work at OS X
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59075 --- Comment #4 from Alexander Timin altimin at altimin dot ru --- Created attachment 31196 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31196action=edit compiled executable
[Bug libstdc++/59075] python pretty printer does not work at OS X
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59075 --- Comment #6 from Alexander Timin altimin at altimin dot ru --- (In reply to Tom Tromey from comment #2) It has been compiled only with -g option. What do you mean by see gdb session? I don't understand. What should I do?
[Bug libstdc++/59075] python pretty printer does not work at OS X
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59075 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Tom, do you know why this would be true on OS X?
