public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/30148] New: Don't print "unknown" for scoped enums with no enumerators
@ 2023-02-20 13:50 jwakely.gcc at gmail dot com
  2023-02-20 13:53 ` [Bug c++/30148] " aburgess at redhat dot com
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: jwakely.gcc at gmail dot com @ 2023-02-20 13:50 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=30148

            Bug ID: 30148
           Summary: Don't print "unknown" for scoped enums with no
                    enumerators
           Product: gdb
           Version: 12.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
          Assignee: unassigned at sourceware dot org
          Reporter: jwakely.gcc at gmail dot com
  Target Milestone: ---

Given this program:

#include <cstddef>
#include <vector>

int main()
{
  std::byte b{0x23};
  std::vector<std::byte> v{ b, std::byte{0x42}};
  return 0;
}

GDB prints this for the two variables:

$1 = (unknown: 0x23)
$2 = std::vector of length 2, capacity 2 = {(unknown: 0x23), (unknown: 0x42)}


The "unknown: " strings are just noise here, because std::byte is just
(mis)using an enum type as a "strong typedef", i.e. an integer-like type that
doesn't convert or promote to other integer types. It's defined as:

enum class byte : unsigned char {};

Every value of unsigned char is a valid value of this type, and there are no
"known" constants of this type.

I think it would be useful to somehow teach GDB that certain enum types are
expected to be used this way, i.e. without enumerators. So GDB wouldn't expect
to "know" the values, and so wouldn't consider any values to be "unknown".

I initially considered some new attribute that would make GCC emit some special
debugingo. But I think we could just Do The Right Thing automatically. A
reasonable heuristic would be if it's declared as a scoped enum (i.e. C++11
enum class) with no enumerators, assume that only the raw integer values
matter, and no values are "unknown".

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug c++/30148] Don't print "unknown" for scoped enums with no enumerators
  2023-02-20 13:50 [Bug c++/30148] New: Don't print "unknown" for scoped enums with no enumerators jwakely.gcc at gmail dot com
@ 2023-02-20 13:53 ` aburgess at redhat dot com
  2023-02-27 14:14 ` cvs-commit at gcc dot gnu.org
  2023-02-27 16:05 ` aburgess at redhat dot com
  2 siblings, 0 replies; 4+ messages in thread
From: aburgess at redhat dot com @ 2023-02-20 13:53 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=30148

Andrew Burgess <aburgess at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aburgess at redhat dot com

--- Comment #1 from Andrew Burgess <aburgess at redhat dot com> ---
Posted patch:

  https://sourceware.org/pipermail/gdb-patches/2023-February/197234.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug c++/30148] Don't print "unknown" for scoped enums with no enumerators
  2023-02-20 13:50 [Bug c++/30148] New: Don't print "unknown" for scoped enums with no enumerators jwakely.gcc at gmail dot com
  2023-02-20 13:53 ` [Bug c++/30148] " aburgess at redhat dot com
@ 2023-02-27 14:14 ` cvs-commit at gcc dot gnu.org
  2023-02-27 16:05 ` aburgess at redhat dot com
  2 siblings, 0 replies; 4+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-02-27 14:14 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=30148

--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrew Burgess <aburgess@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=85c7cb3c4b70cc484ecf3d72a116503876a28f0a

commit 85c7cb3c4b70cc484ecf3d72a116503876a28f0a
Author: Andrew Burgess <aburgess@redhat.com>
Date:   Mon Feb 20 13:14:55 2023 +0000

    gdb: don't treat empty enums as flag enums

    In C++ it is possible to use an empty enum as a strong typedef.  For
    example, a user could write:

      enum class my_type : unsigned char {};

    Now my_type can be used like 'unsigned char' except the compiler will
    not allow implicit conversion too and from the native 'unsigned char'
    type.

    This is used in the standard library for things like std::byte.

    Currently, when GDB prints a value of type my_type, it looks like
    this:

      (gdb) print my_var
      $1 = (unknown: 0x4)

    Which isn't great.  This gets worse when we consider something like:

      std::vector<my_type> vec;

    When using a pretty-printer, this could look like this:

      std::vector of length 2, capacity 2 = {(unknown: 0x2), (unknown: 0x4)}

    Clearly not great.  This is described in PR gdb/30148.

    The problem here is in dwarf2/read.c, we assume all enums are flag
    enums unless we find an enumerator with a non-flag like value.
    Clearly an empty enum contains no non-flag values, so we assume the
    enum is a flag enum.

    I propose adding an extra check here; that is, an empty enum should
    never be a flag enum.

    With this the above cases look more like:

      (gdb) print my_var
      $1 = 4

    and:

      std::vector of length 2, capacity 2 = {2, 4}

    Which look much better.

    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30148

    Reviewed-By: Tom Tromey <tom@tromey.com>

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug c++/30148] Don't print "unknown" for scoped enums with no enumerators
  2023-02-20 13:50 [Bug c++/30148] New: Don't print "unknown" for scoped enums with no enumerators jwakely.gcc at gmail dot com
  2023-02-20 13:53 ` [Bug c++/30148] " aburgess at redhat dot com
  2023-02-27 14:14 ` cvs-commit at gcc dot gnu.org
@ 2023-02-27 16:05 ` aburgess at redhat dot com
  2 siblings, 0 replies; 4+ messages in thread
From: aburgess at redhat dot com @ 2023-02-27 16:05 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=30148

Andrew Burgess <aburgess at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #3 from Andrew Burgess <aburgess at redhat dot com> ---
I believe this is now fixed.  Feel free to reopen if there are still issues in
this area.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2023-02-27 16:05 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-20 13:50 [Bug c++/30148] New: Don't print "unknown" for scoped enums with no enumerators jwakely.gcc at gmail dot com
2023-02-20 13:53 ` [Bug c++/30148] " aburgess at redhat dot com
2023-02-27 14:14 ` cvs-commit at gcc dot gnu.org
2023-02-27 16:05 ` aburgess at redhat dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).