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

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

[Philippe Blain]

Hello,

I'm trying to understand why a 'std::vector<double>' appears in GDB as
'type = vector<double, std::allocator<double> >' instead of 'std::vector<...>'

I have this simple program:
~~~cpp
#include <vector>

void here() {};

int main() {
     std::vector<double> array(4);
     here();

     return 0;
}
~~~

I'm using GCC 7.3 from Homebrew on my macOS 10.11.6 system, but I have similar
behaviour with GCC 10.2 on macOS 10.15.7 in GitHub Actions.

I compile with:

     g++-7 -g -O0 -std=c++11 test.cpp -o test

and run GDB (self-compiled, 11.0.50.20210223-git) with:

     gdb test --batch -ex 'b here' -ex run -ex up -ex 'whatis array'

I get 'type = vector<double, std::allocator<double> >'.
If I compile with '-gdwarf-3' instead of just '-g', then I get
'type = std::vector<double>'.

 From the documentation [1], I understand that '-g' defaults to dwarf-2 on macOS,
but I do not understand what the DWARF version has to do with the fact that 'vector'
is seen by GDB in the global or 'std::' namespace...

The behaviour is similar when debugging with LLDB:

     lldb --batch -o 'b 7' -o r -o 'p array' test

shows '(vector<double, allocator<double> >) $0 = { ...' for DWARF-2
and '(std::vector<double, std::allocator<double> >) $0 =  ...' for DWARF-3.

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...

This is my first post here so I'm sorry if it's not the right forum.
I searched the archives but could not find anything about this.
Also, I am not subscribed to the list so if I could be CC'ed in the replies
this would be ideal.

Cheers!

Philippe.

[1] https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
[2] https://github.com/gcc-mirror/gcc/commit/047a3193bd729475182a438d9929ec923f484481

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

[Iain Sandoe]

Philippe Blain <levraiphilippeblain@gmail.com> wrote:

> I'm trying to understand why a 'std::vector<double>' appears in GDB as
> 'type = vector<double, std::allocator<double> >' instead of  
> 'std::vector<…>’

I can’t help much with the body of this report (how the debug info relates  
to what’s presented) .. hopefully someone more familiar with what is  
representable by each version of debug info can chime in ...

but...

> 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 ?

… This something under review at the moment.

The majority of macOS users are using the assembler, linker and debug  
linker (dsymutil) from some installed version of Xcode.

So that means that whatever DWARF is emitted by GCC has to be compatible  
with those tools;  it takes quite some time to evaluate this for the  
versions of system and xcode out there (we had numerous issues especially  
with the tools based on dwarfutils whenever trying to move to > dwarf 2 -  
recently I revaluated this because we would like DWARF-3 to support D - and  
it’s still not viable on many system versions).

I am hopeful that we will be able to switch to default of DWARF-4 for macOS  
versions >= 10.10 sometime in GCC12 (it might be that we have to check for  
suitable support from dsymutil, and I have some patches for that to apply  
in next stage #1).

You say you’re using 10.11.6  and 10.15.7, and I’m assuming you have XCode  
command line tools (or App) >= 7.2 installed.  In that case, it’s probable  
that you will have good results from using -gdwarf-4 ( I guess if it’s  
iritating enough to have to do that, you could always change the default  
and rebuild the compiler ;) ).

FWIW, in general, I find that debugging complex C++ (e.g. the compilers)  
works pretty well with default settings and -O0 -g on macOS 10.12 and  
higher (but mostly using lldb as the debugger).

Iain

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

[Jonathan Wakely]

On 04/03/21 17:51 -0500, Philippe Blain via Libstdc++ wrote:
>Hello,
>
>I'm trying to understand why a 'std::vector<double>' appears in GDB as
>'type = vector<double, std::allocator<double> >' instead of 'std::vector<...>'
>
>I have this simple program:
>~~~cpp
>#include <vector>
>
>void here() {};
>
>int main() {
>    std::vector<double> array(4);
>    here();
>
>    return 0;
>}
>~~~
>
>I'm using GCC 7.3 from Homebrew on my macOS 10.11.6 system, but I have similar
>behaviour with GCC 10.2 on macOS 10.15.7 in GitHub Actions.
>
>I compile with:
>
>    g++-7 -g -O0 -std=c++11 test.cpp -o test
>
>and run GDB (self-compiled, 11.0.50.20210223-git) with:
>
>    gdb test --batch -ex 'b here' -ex run -ex up -ex 'whatis array'
>
>I get 'type = vector<double, std::allocator<double> >'.
>If I compile with '-gdwarf-3' instead of just '-g', then I get
>'type = std::vector<double>'.
>
From the documentation [1], I understand that '-g' defaults to dwarf-2 on macOS,
>but I do not understand what the DWARF version has to do with the fact that 'vector'
>is seen by GDB in the global or 'std::' namespace...

I can't reproduce this using -gdwarf-2 on GNU/Linux, so it seems to be
a peculiarity of DWARF 2 on MacOS. Either what GCC emits, or what GDB
consumes.

>The behaviour is similar when debugging with LLDB:
>
>    lldb --batch -o 'b 7' -o r -o 'p array' test
>
>shows '(vector<double, allocator<double> >) $0 = { ...' for DWARF-2
>and '(std::vector<double, std::allocator<double> >) $0 =  ...' for DWARF-3.
>
>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 wonder if this affects Windows too, and other targets that don't use
the ELF library naming scheme.

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

[Philippe Blain]

Hi Jonathan,

Le 2021-03-05 à 13:19, Jonathan Wakely a écrit :
> On 04/03/21 17:51 -0500, Philippe Blain via Libstdc++ wrote:
>> Hello,
>>
>> I'm trying to understand why a 'std::vector<double>' appears in GDB as
>> 'type = vector<double, std::allocator<double> >' instead of 'std::vector<...>'
>>
>> I have this simple program:
>> ~~~cpp
>> #include <vector>
>>
>> void here() {};
>>
>> int main() {
>>    std::vector<double> array(4);
>>    here();
>>
>>    return 0;
>> }
>> ~~~
>>
>> I'm using GCC 7.3 from Homebrew on my macOS 10.11.6 system, but I have similar
>> behaviour with GCC 10.2 on macOS 10.15.7 in GitHub Actions.
>>
>> I compile with:
>>
>>    g++-7 -g -O0 -std=c++11 test.cpp -o test
>>
>> and run GDB (self-compiled, 11.0.50.20210223-git) with:
>>
>>    gdb test --batch -ex 'b here' -ex run -ex up -ex 'whatis array'
>>
>> I get 'type = vector<double, std::allocator<double> >'.
>> If I compile with '-gdwarf-3' instead of just '-g', then I get
>> 'type = std::vector<double>'.
>>
>> From the documentation [1], I understand that '-g' defaults to dwarf-2 on macOS,
>> but I do not understand what the DWARF version has to do with the fact that 'vector'
>> is seen by GDB in the global or 'std::' namespace...
> 
> I can't reproduce this using -gdwarf-2 on GNU/Linux, so it seems to be
> a peculiarity of DWARF 2 on MacOS. Either what GCC emits, or what GDB
> consumes.

Yes, I also tried on Ubuntu 18 and couldn't reproduce either (sorry
for not mentioning!).

>> The behaviour is similar when debugging with LLDB:
>>
>>    lldb --batch -o 'b 7' -o r -o 'p array' test
>>
>> shows '(vector<double, allocator<double> >) $0 = { ...' for DWARF-2
>> and '(std::vector<double, std::allocator<double> >) $0 =  ...' for DWARF-3.
I would think it's what GCC emits though, since LLDB acts similarly (although
I could be wrong...)

>>
>> 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.
However, the pretty printers do work because they install a global gdbinit
at $installdir\etc\gdbinit with the following content:

python
import sys
sys.path.insert(0, sys.path[0] + '/../../gcc-8.1.0/python')
from libstdcxx.v6.printers import register_libstdcxx_printers
register_libstdcxx_printers (None)
end

So I guess they are always loaded... I did not check other Windows
distributions of GDB/GCC.

Thanks for answering,

Philippe.

Re: 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.

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

[Iain Sandoe]

Jonathan Wakely <jwakely.gcc@gmail.com> 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.

(unfortunately, I’m not familiar with exactly what language features can be  
represented by each DWARF revision but, hypothetically, it could be that  
something in the current sources is not representable properly by DWARF-2)

Notes

  * Darwin defaults to dwarf-2 and also strict-dwarf.
  * dwarfdump —verify does not report any issues for the object files produced by the example command lines below.

So that [on Darwin16 / macOS 10.12]
g++ /source/test/cxx/debug-vect.C -save-temps -o t -g

=>

(lldb) p array
(vector<double, allocator<double> >) $0 = {
   _Vector_base<double, allocator<double> > = {
     _M_impl = {
       _Vector_impl_data = {
         _M_start = 0x0000000100501f40
         _M_finish = 0x0000000100501f60
         _M_end_of_storage = 0x0000000100501f60
       }
     }
   }
}

but
g++ /source/test/cxx/debug-vect.C -save-temps -o t -g -gno-strict-dwarf  
-gdwarf-2

(lldb) p array
(std::vector<double, std::allocator<double> >) $0 = size=4 {
   [0] = 0
   [1] = 0
   [2] = 0
   [3] = 0
}

=====

So I think one would have to try “-gdwarf-2 -gstrict-dwarf -g” on Linux to  
make a proper comparison - and my results for that were inconclusive -  
since I got:

(gdb) p array
Could not find the frame base for "main()".

So there was no output for the array case to compare (could be a different  
problem or a separate manifestation of the same one).

Iain

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

[Jonathan Wakely]

On 07/03/21 12:23 +0000, Iain Sandoe wrote:
>Jonathan Wakely <jwakely.gcc@gmail.com> 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.
>
>(unfortunately, I’m not familiar with exactly what language features 
>can be represented by each DWARF revision but, hypothetically, it 
>could be that something in the current sources is not representable 
>properly by DWARF-2)
>
>Notes
>
> * Darwin defaults to dwarf-2 and also strict-dwarf.
> * dwarfdump —verify does not report any issues for the object files produced by the example command lines below.
>
>So that [on Darwin16 / macOS 10.12]
>g++ /source/test/cxx/debug-vect.C -save-temps -o t -g
>
>=>
>
>(lldb) p array
>(vector<double, allocator<double> >) $0 = {
>  _Vector_base<double, allocator<double> > = {
>    _M_impl = {
>      _Vector_impl_data = {
>        _M_start = 0x0000000100501f40
>        _M_finish = 0x0000000100501f60
>        _M_end_of_storage = 0x0000000100501f60
>      }
>    }
>  }
>}
>
>but
>g++ /source/test/cxx/debug-vect.C -save-temps -o t -g 
>-gno-strict-dwarf -gdwarf-2
>
>(lldb) p array
>(std::vector<double, std::allocator<double> >) $0 = size=4 {
>  [0] = 0
>  [1] = 0
>  [2] = 0
>  [3] = 0
>}
>
>=====
>
>So I think one would have to try “-gdwarf-2 -gstrict-dwarf -g” on 

Ah, I wasn't using -gstrict-dwarf but if I add that I can reproduce
the problem on GNU/Linux with current versions of GCC and GDB.

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

[Philippe Blain]

Hello again,

Le 2021-03-07 à 11:07, Jonathan Wakely a écrit :
> On 07/03/21 12:23 +0000, Iain Sandoe wrote:
>> Jonathan Wakely <jwakely.gcc@gmail.com> 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.
>>
>> (unfortunately, I’m not familiar with exactly what language features can be represented by each DWARF revision but, hypothetically, it could be that something in the current sources is not representable properly by DWARF-2)
>>
>> Notes
>>
>> * Darwin defaults to dwarf-2 and also strict-dwarf.
>> * dwarfdump —verify does not report any issues for the object files produced by the example command lines below.
>>
>> So that [on Darwin16 / macOS 10.12]
>> g++ /source/test/cxx/debug-vect.C -save-temps -o t -g
>>
>> =>
>>
>> (lldb) p array
>> (vector<double, allocator<double> >) $0 = {
>>  _Vector_base<double, allocator<double> > = {
>>    _M_impl = {
>>      _Vector_impl_data = {
>>        _M_start = 0x0000000100501f40
>>        _M_finish = 0x0000000100501f60
>>        _M_end_of_storage = 0x0000000100501f60
>>      }
>>    }
>>  }
>> }
>>
>> but
>> g++ /source/test/cxx/debug-vect.C -save-temps -o t -g -gno-strict-dwarf -gdwarf-2
>>
>> (lldb) p array
>> (std::vector<double, std::allocator<double> >) $0 = size=4 {
>>  [0] = 0
>>  [1] = 0
>>  [2] = 0
>>  [3] = 0
>> }
>>
>> =====
>>
>> So I think one would have to try “-gdwarf-2 -gstrict-dwarf -g” on 
> 
> Ah, I wasn't using -gstrict-dwarf but if I add that I can reproduce
> the problem on GNU/Linux with current versions of GCC and GDB.
> 

Looking at the summary of the changes in DWARF 3 [1] it seems
C++ namespaces were added in that revision of the standard, so maybe
in a way it does make sense for "-gdwarf-2 -gstrict-dwarf -g" to not show
'vector' in the 'std' namespace since DWARF 2 does not know about namespaces...

[1] http://dwarfstd.org/Dwarf3Std.php

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

[Iain Sandoe]

Hi Philippe,

Philippe Blain <levraiphilippeblain@gmail.com> wrote:

> Le 2021-03-07 à 11:07, Jonathan Wakely a écrit :
>> On 07/03/21 12:23 +0000, Iain Sandoe wrote:
>>> Jonathan Wakely <jwakely.gcc@gmail.com> 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…)

>>> (unfortunately, I’m not familiar with exactly what language features  
>>> can be represented by each DWARF revision but, hypothetically, it could  
>>> be that something in the current sources is not representable properly  
>>> by DWARF-2)
>>>
>>>

>>> So I think one would have to try “-gdwarf-2 -gstrict-dwarf -g” on
>> Ah, I wasn't using -gstrict-dwarf but if I add that I can reproduce
>> the problem on GNU/Linux with current versions of GCC and GDB.
>
> Looking at the summary of the changes in DWARF 3 [1] it seems
> C++ namespaces were added in that revision of the standard, so maybe
> in a way it does make sense for "-gdwarf-2 -gstrict-dwarf -g" to not show
> 'vector' in the 'std' namespace since DWARF 2 does not know about  
> namespaces…

indeed
>
> [1] http://dwarfstd.org/Dwarf3Std.php

thanks for doing the checking!

----

For GCC12, at least for macOS >= 10.10, I am going to look into changing the
default to DWARF-4.  The problem is not really with GCC itself, but that GCC
relies on the assembler/linker and more importantly debug linker (dsymutil)  
from
Xcode, so it’s important that the versions used there support the  
constructs we emit.

In the meantime, I would expect that if you are using GCC on >= macOS 10.10  
it
would be reasonable to put -gdwarf-4 on the command lines.  Before that, the
support might be unreliable.

thanks
Iain

Re: 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.

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

[Philippe Blain]

Hi,

Le 2021-03-07 à 11:08, Jonathan Wakely a écrit :
> On 07/03/21 08:09 +0000, Jonathan Wakely via Libstdc++ wrote:
>>> >
>>> > 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.

I searched for other *-gdb.py files on my system and looked at the
build process for these projetcs, and found one interesting example
for libisl, where it looks like they rely on the libtool *.la file
to get the right name for the (shared or not) library:

https://repo.or.cz/isl.git/blob/HEAD:/Makefile.am#l611

Maybe something similar could be done.

I'll add that to the bugzilla entry once my account is created.

Philippe.