aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/gdb.base/pending.exp
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2023-02-20 13:14:55 +0000
committerAndrew Burgess <aburgess@redhat.com>2023-02-27 14:14:24 +0000
commit85c7cb3c4b70cc484ecf3d72a116503876a28f0a (patch)
tree41c352a475613a9d0719130375c066c872c7ace7 /gdb/testsuite/gdb.base/pending.exp
parent8034b0baeac1b209b1742b3e8fa25015191b57b8 (diff)
downloadgdb-85c7cb3c4b70cc484ecf3d72a116503876a28f0a.zip
gdb-85c7cb3c4b70cc484ecf3d72a116503876a28f0a.tar.gz
gdb-85c7cb3c4b70cc484ecf3d72a116503876a28f0a.tar.bz2
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>
Diffstat (limited to 'gdb/testsuite/gdb.base/pending.exp')
0 files changed, 0 insertions, 0 deletions