DWARF debug info version on macOS and 'std::' namespace (and pretty-printers)

[Jonathan Wakely]

On Sun, 7 Mar 2021, 05:12 Philippe Blain via Libstdc++, <
libstdc++@gcc.gnu.org> wrote:

>
> I would think it's what GCC emits though, since LLDB acts similarly
> (although
> I could be wrong...)
>

Yes, seems likely to be a GCC problem.


>>
> >> Incidentally, it seems that defaulting to DWARF-2 on macOS is a
> decision taken in 2009
> >> (stemming from 047a3193bd729475182a438d9929ec923f484481, From-SVN:
> r152127 [2])
> >> and I'm wondering if it's still the best thing to do ?
> >>
> >> Finally, I was dragged down this hole trying to understand why the
> Python pretty-printers
> >> were not working on my machine. Having 'vector' correctly identified in
> the 'std::' namespace
> >> was one part of the solution, but I also had to create a symlink named
> >> /usr/local/Cellar/gcc/7.3.0_1/lib/gcc/7/libstdc++.6.dylib-gdb.py
> >> pointing to the existing
> /usr/local/Cellar/gcc/7.3.0_1/lib/gcc/7/libstdc++.a-gdb.py
> >> for the pretty printers to be loaded automatically. Looking at
> gcc/libstdc++-v3/python/Makefile.am
> >> it seems that a file named 'libstdc++.6.dylib-gdb.py' *should* have
> been created
> >> (at least from what I understand), but it seems this is not the case...
> >> I'm not sure why either. I also verified that on the GitHub Actions VM,
> for
> >> GCC 8, 9 and 10, only libstdc++.a-gdb.py exists...
> >
> > I think we only install it with one name. For ELF targets that is the
> > shared library name:
> >
> >   /usr/bin/install -c -m 644 gdb.py
> /home/jwakely/gcc/11/lib/../lib64/libstdc++.so.6.0.29-gdb.py
> >
> > The code loops over libstdc++.* (i.e. using the shell's sorting rules)
> > and takes the last name that isn't a symlink and isn't a .la or .py
> > file. For ELF targets where we have these names, the last one is the
> > one we want to use:
> >
> > libstdc++.a
> > libstdc++.so
> > libstdc++.so.6
> > libstdc++.so.6.0.29
> >
> > But if you have these names:
> >
> > libstdc++.6.dylib
> > libstdc++.a
> >
> > then the last one is going to be the .a not the dylib.
> >
> > It shouldn't be *too* hard to fix that.
>
> I'll try to have a look into that.
>
> >
> > I wonder if this affects Windows too, and other targets that don't use
> > the ELF library naming scheme.
>
> I'm new to Windows, but I just installed MinGW-w64 (that includes GDB)
> to check. The *-gdb.py file for libstdc++ is actually at the following
> path:
>
> $installdir\lib\gcc\x86_64-w64-mingw32\8.1.0\libstdc++.dll.a-gdb.py
>
> but the actual dynamic library used in compiled programs (checked with
> "info shared" in GDB) is $installdir\bin\libstdc++-6.dll.
>

Yep, so the wrong one.


However, the pretty printers do work because they install a global gdbinit
> at $installdir\etc\gdbinit with the following content:
>

Hmm, that looks like a mingw-w64 workaround. It looks suboptimal, because
it assumes you only have one version of GCC in use.

I'll try to fix the makefile so it does the right thing for Windows too.

Thanks for bringing this to our attention.