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

[Jonathan Wakely]

On 07/03/21 08:09 +0000, Jonathan Wakely via Libstdc++ wrote:
>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.

I've opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453 for
this problem installing the Python file.