Bug 59075 - python pretty printer does not work at OS X
Summary: python pretty printer does not work at OS X
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 4.6.4
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-10 23:11 UTC by Alexander Timin
Modified: 2018-11-23 23:15 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2016-04-12 00:00:00


Attachments
compiled dwarf file (14.81 KB, application/zip)
2013-11-11 23:37 UTC, Alexander Timin
Details
compiled executable (7.03 KB, application/octet-stream)
2013-11-11 23:38 UTC, Alexander Timin
Details
source code (110 bytes, text/x-csrc)
2013-11-11 23:39 UTC, Alexander Timin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Timin 2013-11-10 23:11:14 UTC
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)
Comment 1 Jonathan Wakely 2013-11-11 00:00:19 UTC
Tom, do you know why this would be true on OS X?
Comment 2 Tom Tromey 2013-11-11 17:35:51 UTC
(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.
Comment 3 Alexander Timin 2013-11-11 23:37:58 UTC
Created attachment 31195 [details]
compiled dwarf file
Comment 4 Alexander Timin 2013-11-11 23:38:40 UTC
Created attachment 31196 [details]
compiled executable
Comment 5 Alexander Timin 2013-11-11 23:39:03 UTC
Created attachment 31197 [details]
source code
Comment 6 Alexander Timin 2013-11-11 23:48:52 UTC
(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?
Comment 7 manuelrciosici 2016-04-12 09:32:04 UTC
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>
Comment 8 Jonathan Wakely 2016-04-12 12:17:21 UTC
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?
Comment 9 manuelrciosici 2017-03-01 16:29:42 UTC
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?
Comment 10 Jonathan Wakely 2018-11-23 12:33:21 UTC
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?
Comment 11 Iain Sandoe 2018-11-23 13:11:05 UTC
(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.
Comment 12 Eric Gallager 2018-11-23 23:15:45 UTC
(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.