Python pretty printing does not work at Mac OS X 10.9 (g++ 4.6.4, gdb 7.6) because result of get_basic_type() is just 'vector' instead of 'std::vector'. Adding following two lines to add_version method of Printer class worked for me. if base == 'std::': self.add(name, function)
Tom, do you know why this would be true on OS X?
(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.
Created attachment 31195 [details] compiled dwarf file
Created attachment 31196 [details] compiled executable
Created attachment 31197 [details] source code
(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?
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<unsigned long, std::allocator<unsigned long> > [with _Tp = unsigned long, _Alloc = allocator<unsigned long>] : protected _Vector_base<_Tp, std::_Alloc>
Odd, on GNU/Linux I get: type = class std::vector<unsigned long, std::allocator<unsigned long> > : protected std::_Vector_base<unsigned long, std::allocator<unsigned long> > { 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?
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<unsigned long, std::allocator<unsigned long> > : > protected std::_Vector_base<unsigned long, std::allocator<unsigned long> > { > > > 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?
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?
(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. == 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.
(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.