Re: printers.py issue

Re: printers.py issue

[Jonathan Wakely]

On Fri, 26 Feb 2021, 21:59 Hoyer, David via Gcc, <gcc@gcc.gnu.org> wrote:

> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
> OFFLOAD_TARGET_NAMES=nvptx-none
> OFFLOAD_TARGET_DEFAULT=1
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6'
> --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
> --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
> --with-gcc-major-version-only --program-suffix=-8
> --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
> --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object
> --disable-vtable-verify --enable-libmpx --enable-plugin
> --enable-default-pie --with-system-zlib --with-target-system-zlib
> --enable-objc-gc=auto --enable-multiarch --disable-werror
> --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
> --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none
> --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
> --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 8.3.0 (Debian 8.3.0-6)
>
> We are noticing some problems using GDB with printers.py
>

This belongs on the libstdc++ list, CC'd.

Which version of GDB are you using, and which version of Python does it use?



>
>

RE: printers.py issue

[Hoyer, David]

Thank you for redirecting to the correct group!

Requested version information:
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Python 3.7.3

From: Jonathan Wakely <jwakely.gcc@gmail.com>
Sent: Friday, February 26, 2021 4:27 PM
To: Hoyer, David <David.Hoyer@netapp.com>
Cc: gcc@gcc.gnu.org; libstdc++ <libstdc++@gcc.gnu.org>
Subject: Re: printers.py issue

NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.



On Fri, 26 Feb 2021, 21:59 Hoyer, David via Gcc, <gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org>> wrote:
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-6)

We are noticing some problems using GDB with printers.py

This belongs on the libstdc++ list, CC'd.

Which version of GDB are you using, and which version of Python does it use?

RE: printers.py issue

[Hoyer, David]

I just realized that some of my original email explaining the issue was removed from the thread

Problem 1:  the function find_type was changed such that search now uses typ.unqualified() instead of typ.name.
In the case of a class, the former prepends class to the search string so that when it runs gdb.lookup_type(search), it does not find the definition.   If I switch it back to typ.name, this function works

Problem 2:  We are seeing an error in strip_versioned_namespace
  File "/usr/lib/x86_64-linux-gnu/../../share/gcc-8/python/libstdcxx/v6/printers.py", line 668, in __init__
      self.typename = strip_versioned_namespace(typename)
  File "/usr/lib/x86_64-linux-gnu/../../share/gcc-8/python/libstdcxx/v6/printers.py", line 114, in strip_versioned_namespace
    return typename.replace(_versioned_namespace, '')
AttributeError: 'gdb.Type' object has no attribute 'replace'
Error occurred in Python command: 'gdb.Type' object has no attribute 'replace'


From: Hoyer, David
Sent: Friday, February 26, 2021 4:31 PM
To: Jonathan Wakely <jwakely.gcc@gmail.com>
Cc: gcc@gcc.gnu.org; libstdc++ <libstdc++@gcc.gnu.org>
Subject: RE: printers.py issue

Thank you for redirecting to the correct group!

Requested version information:
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Python 3.7.3

From: Jonathan Wakely <jwakely.gcc@gmail.com<mailto:jwakely.gcc@gmail.com>>
Sent: Friday, February 26, 2021 4:27 PM
To: Hoyer, David <David.Hoyer@netapp.com<mailto:David.Hoyer@netapp.com>>
Cc: gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org>; libstdc++ <libstdc++@gcc.gnu.org<mailto:libstdc++@gcc.gnu.org>>
Subject: Re: printers.py issue

NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.


On Fri, 26 Feb 2021, 21:59 Hoyer, David via Gcc, <gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org>> wrote:
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-6)

We are noticing some problems using GDB with printers.py

This belongs on the libstdc++ list, CC'd.

Which version of GDB are you using, and which version of Python does it use?

Re: printers.py issue

[Jonathan Wakely]

On 04/03/21 04:35 +0000, Hoyer, David via Libstdc++ wrote:
>I just realized that some of my original email explaining the issue was removed from the thread

Yes, my fault, sorry.

>Problem 1:  the function find_type was changed such that search now uses typ.unqualified() instead of typ.name.
>In the case of a class, the former prepends class to the search string so that when it runs gdb.lookup_type(search), it does not find the definition.   If I switch it back to typ.name, this function works

But typ.name doesn't exist in GDB 7.6, which is why it's not used. See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67440 for the history.

The differences between gdb.Type.name and gdb.Type.tag and
str(gdb.Type) in different versions of GCC and/or GDB  are a non-stop
pain in the arse.

I think typ.unqualified().tag should work consistently. Maybe even
typ.tag but I don't trust it.


>Problem 2:  We are seeing an error in strip_versioned_namespace
>  File "/usr/lib/x86_64-linux-gnu/../../share/gcc-8/python/libstdcxx/v6/printers.py", line 668, in __init__
>      self.typename = strip_versioned_namespace(typename)
>  File "/usr/lib/x86_64-linux-gnu/../../share/gcc-8/python/libstdcxx/v6/printers.py", line 114, in strip_versioned_namespace
>    return typename.replace(_versioned_namespace, '')
>AttributeError: 'gdb.Type' object has no attribute 'replace'
>Error occurred in Python command: 'gdb.Type' object has no attribute 'replace'

This one would be easy to fix by converting to a string first.  But I
wonder why it isn't failing for everybody. All calls to the function
strip_versioned_namespace should be getting passed a string, not a
gdb.Type object.


>
>From: Hoyer, David
>Sent: Friday, February 26, 2021 4:31 PM
>To: Jonathan Wakely <jwakely.gcc@gmail.com>
>Cc: gcc@gcc.gnu.org; libstdc++ <libstdc++@gcc.gnu.org>
>Subject: RE: printers.py issue
>
>Thank you for redirecting to the correct group!
>
>Requested version information:
>GNU gdb (Debian 8.2.1-2+b3) 8.2.1
>Python 3.7.3
>
>From: Jonathan Wakely <jwakely.gcc@gmail.com<mailto:jwakely.gcc@gmail.com>>
>Sent: Friday, February 26, 2021 4:27 PM
>To: Hoyer, David <David.Hoyer@netapp.com<mailto:David.Hoyer@netapp.com>>
>Cc: gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org>; libstdc++ <libstdc++@gcc.gnu.org<mailto:libstdc++@gcc.gnu.org>>
>Subject: Re: printers.py issue
>
>NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
>On Fri, 26 Feb 2021, 21:59 Hoyer, David via Gcc, <gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org>> wrote:
>COLLECT_GCC=gcc
>COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
>OFFLOAD_TARGET_NAMES=nvptx-none
>OFFLOAD_TARGET_DEFAULT=1
>Target: x86_64-linux-gnu
>Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
>Thread model: posix
>gcc version 8.3.0 (Debian 8.3.0-6)
>
>We are noticing some problems using GDB with printers.py
>
>This belongs on the libstdc++ list, CC'd.
>
>Which version of GDB are you using, and which version of Python does it use?
>
>
>

RE: printers.py issue

[Hoyer, David]

Thank you for this feedback.   We are certainly writing our own pretty-print functions which leverage the printers.py function.    These worked fine with the jessie GCC and stretch GDB.    I will continue to investigate from my end to see if we are doing something wrong (heaven forbid that be possible 😉)

-----Original Message-----
From: Jonathan Wakely <jwakely@redhat.com> 
Sent: Thursday, March 4, 2021 5:47 AM
To: Hoyer, David <David.Hoyer@netapp.com>
Cc: Jonathan Wakely <jwakely.gcc@gmail.com>; libstdc++ <libstdc++@gcc.gnu.org>
Subject: Re: printers.py issue

NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.




On 04/03/21 04:35 +0000, Hoyer, David via Libstdc++ wrote:
>I just realized that some of my original email explaining the issue was 
>removed from the thread

Yes, my fault, sorry.

>Problem 1:  the function find_type was changed such that search now uses typ.unqualified() instead of typ.name.
>In the case of a class, the former prepends class to the search string so that when it runs gdb.lookup_type(search), it does not find the definition.   If I switch it back to typ.name, this function works

But typ.name doesn't exist in GDB 7.6, which is why it's not used. See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67440 for the history.

The differences between gdb.Type.name and gdb.Type.tag and
str(gdb.Type) in different versions of GCC and/or GDB  are a non-stop pain in the arse.

I think typ.unqualified().tag should work consistently. Maybe even typ.tag but I don't trust it.


>Problem 2:  We are seeing an error in strip_versioned_namespace
>  File "/usr/lib/x86_64-linux-gnu/../../share/gcc-8/python/libstdcxx/v6/printers.py", line 668, in __init__
>      self.typename = strip_versioned_namespace(typename)
>  File "/usr/lib/x86_64-linux-gnu/../../share/gcc-8/python/libstdcxx/v6/printers.py", line 114, in strip_versioned_namespace
>    return typename.replace(_versioned_namespace, '')
>AttributeError: 'gdb.Type' object has no attribute 'replace'
>Error occurred in Python command: 'gdb.Type' object has no attribute 'replace'

This one would be easy to fix by converting to a string first.  But I wonder why it isn't failing for everybody. All calls to the function strip_versioned_namespace should be getting passed a string, not a gdb.Type object.


>
>From: Hoyer, David
>Sent: Friday, February 26, 2021 4:31 PM
>To: Jonathan Wakely <jwakely.gcc@gmail.com>
>Cc: gcc@gcc.gnu.org; libstdc++ <libstdc++@gcc.gnu.org>
>Subject: RE: printers.py issue
>
>Thank you for redirecting to the correct group!
>
>Requested version information:
>GNU gdb (Debian 8.2.1-2+b3) 8.2.1
>Python 3.7.3
>
>From: Jonathan Wakely 
><jwakely.gcc@gmail.com<mailto:jwakely.gcc@gmail.com>>
>Sent: Friday, February 26, 2021 4:27 PM
>To: Hoyer, David 
><David.Hoyer@netapp.com<mailto:David.Hoyer@netapp.com>>
>Cc: gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org>; libstdc++ 
><libstdc++@gcc.gnu.org<mailto:libstdc++@gcc.gnu.org>>
>Subject: Re: printers.py issue
>
>NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
>On Fri, 26 Feb 2021, 21:59 Hoyer, David via Gcc, <gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org>> wrote:
>COLLECT_GCC=gcc
>COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
>OFFLOAD_TARGET_NAMES=nvptx-none
>OFFLOAD_TARGET_DEFAULT=1
>Target: x86_64-linux-gnu
>Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6' 
>--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs 
>--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ 
>--prefix=/usr --with-gcc-major-version-only --program-suffix=-8 
>--program-prefix=x86_64-linux-gnu- --enable-shared 
>--enable-linker-build-id --libexecdir=/usr/lib 
>--without-included-gettext --enable-threads=posix --libdir=/usr/lib 
>--enable-nls --enable-bootstrap --enable-clocale=gnu 
>--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
>--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
>--disable-vtable-verify --enable-libmpx --enable-plugin 
>--enable-default-pie --with-system-zlib --with-target-system-zlib 
>--enable-objc-gc=auto --enable-multiarch --disable-werror 
>--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 
>--enable-multilib --with-tune=generic 
>--enable-offload-targets=nvptx-none --without-cuda-driver 
>--enable-checking=release --build=x86_64-linux-gnu 
>--host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix 
>gcc version 8.3.0 (Debian 8.3.0-6)
>
>We are noticing some problems using GDB with printers.py
>
>This belongs on the libstdc++ list, CC'd.
>
>Which version of GDB are you using, and which version of Python does it use?
>
>
>

Re: printers.py issue

[Jonathan Wakely]

On 04/03/21 14:19 +0000, Hoyer, David via Libstdc++ wrote:
>Thank you for this feedback.   We are certainly writing our own pretty-print functions which leverage the printers.py function.    These worked fine with the jessie GCC and stretch GDB.    I will continue to investigate from my end to see if we are doing something wrong (heaven forbid that be possible 😉)

I see. Then it might be possible that you're constructing a
StdSetPrinter with a gdb.Type object as the "typename" argument. I
when the libstdc++ printers are created they are always given a string
for that argument.

For problem 1 (the typ.unqualified() issue) I've done some digging
(see https://sourceware.org/bugzilla/show_bug.cgi?id=27510 for
details) and although I remain confused, I think typ.tag is what we
want. We've already done strip_typedefs() so we should have a class
type by that point, and .tag will be the unqualified class name.

I'll test this patch:

--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -85,8 +85,8 @@ except ImportError:
  def find_type(orig, name):
      typ = orig.strip_typedefs()
      while True:
-        # Strip cv-qualifiers.  PR 67440.
-        search = '%s::%s' % (typ.unqualified(), name)
+        # Use Type.tag to ignore cv-qualifiers.  PR 67440.
+        search = '%s::%s' % (typ.tag, name)
          try:
              return gdb.lookup_type(search)
          except RuntimeError:

RE: printers.py issue

[Hoyer, David]

I wanted to finally follow up on these issues I reported.

On issue 1, the patch you provided did fix the problem
On issue 2, I changed our python script to convert it to a string and it now works!

-----Original Message-----
From: Jonathan Wakely <jwakely@redhat.com> 
Sent: Thursday, March 4, 2021 8:57 AM
To: Hoyer, David <David.Hoyer@netapp.com>
Cc: libstdc++ <libstdc++@gcc.gnu.org>
Subject: Re: printers.py issue

NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.




On 04/03/21 14:19 +0000, Hoyer, David via Libstdc++ wrote:
>Thank you for this feedback.   We are certainly writing our own pretty-print functions which leverage the printers.py function.    These worked fine with the jessie GCC and stretch GDB.    I will continue to investigate from my end to see if we are doing something wrong (heaven forbid that be possible 😉)

I see. Then it might be possible that you're constructing a StdSetPrinter with a gdb.Type object as the "typename" argument. I when the libstdc++ printers are created they are always given a string for that argument.

For problem 1 (the typ.unqualified() issue) I've done some digging (see https://sourceware.org/bugzilla/show_bug.cgi?id=27510 for
details) and although I remain confused, I think typ.tag is what we want. We've already done strip_typedefs() so we should have a class type by that point, and .tag will be the unqualified class name.

I'll test this patch:

--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -85,8 +85,8 @@ except ImportError:
  def find_type(orig, name):
      typ = orig.strip_typedefs()
      while True:
-        # Strip cv-qualifiers.  PR 67440.
-        search = '%s::%s' % (typ.unqualified(), name)
+        # Use Type.tag to ignore cv-qualifiers.  PR 67440.
+        search = '%s::%s' % (typ.tag, name)
          try:
              return gdb.lookup_type(search)
          except RuntimeError:

Re: printers.py issue

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

On 10/03/21 16:57 +0000, Hoyer, David wrote:
>I wanted to finally follow up on these issues I reported.
>
>On issue 1, the patch you provided did fix the problem

Thanks for confirming. It's committed to the master branch now (as
attached to this mail). I also plan to backport it to the active
release branches later.

>On issue 2, I changed our python script to convert it to a string and it now works!

Great. I think it's correct that those constructor methods expect
strings for the 'typename' parameter.




[-- Attachment #2: patch.txt --]
[-- Type: text/x-patch, Size: 1576 bytes --]

commit 9dacc828bf8b087ddfaf797ed7238da45609082c
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Mar 11 16:48:32 2021

    libstdc++: Fix find_type helper to work consistently
    
    The find_type helper function sometimes results in "class X::name" and
    lookup for that fails. For more details see "Problem 1" in
    https://gcc.gnu.org/pipermail/libstdc++/2021-March/052132.html and the
    example at https://sourceware.org/bugzilla/show_bug.cgi?id=27510#c2
    
    This patch replaces typ.unqualified() with typ.tag, which is never
    qualified, and will never include the 'class' or 'struct' keywords.
    Using the .tag attribute should be safe here because we know we are
    looking at a class type and we've already used strip_typedefs().
    
    libstdc++-v3/ChangeLog:
    
            * python/libstdcxx/v6/printers.py (find_type): Use tag attribute
            instead of unqualified() method.

diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py b/libstdc++-v3/python/libstdcxx/v6/printers.py
index 00db6cb4e82..550e0ecdd22 100644
--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -85,8 +85,8 @@ except ImportError:
 def find_type(orig, name):
     typ = orig.strip_typedefs()
     while True:
-        # Strip cv-qualifiers.  PR 67440.
-        search = '%s::%s' % (typ.unqualified(), name)
+        # Use Type.tag to ignore cv-qualifiers.  PR 67440.
+        search = '%s::%s' % (typ.tag, name)
         try:
             return gdb.lookup_type(search)
         except RuntimeError:

RE: printers.py issue

[Hoyer, David]

Thank you so much for taking the time to help me with this!   It was greatly appreciated.

-----Original Message-----
From: Jonathan Wakely <jwakely@redhat.com> 
Sent: Thursday, March 11, 2021 11:56 AM
To: Hoyer, David <David.Hoyer@netapp.com>
Cc: libstdc++ <libstdc++@gcc.gnu.org>; gcc-patches@gcc.gnu.org
Subject: Re: printers.py issue

NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.




On 10/03/21 16:57 +0000, Hoyer, David wrote:
>I wanted to finally follow up on these issues I reported.
>
>On issue 1, the patch you provided did fix the problem

Thanks for confirming. It's committed to the master branch now (as attached to this mail). I also plan to backport it to the active release branches later.

>On issue 2, I changed our python script to convert it to a string and it now works!

Great. I think it's correct that those constructor methods expect strings for the 'typename' parameter.