Basic ambiguity detection assumes that when 2 fields with the same name
have the same byte offset, it must be an unambiguous request. This is not
always correct. Consider the following code:
class empty { };
class A {
public:
[[no_unique_address]] empty e;
};
class B {
public:
int e;
};
class C: public A, public B { };
if we tried to use c.e in code, the compiler would warn of an ambiguity,
however, since A::e does not demand an unique address, it gets the same
address (and thus byte offset) of the members, making A::e and B::e have the
same address. however, "print c.e" would fail to report the ambiguity,
and would instead print it as an empty class (first path found).
The new code solves this by checking for other found_fields that have
different m_struct_path.back() (final class that the member was found
in), despite having the same byte offset.
The testcase gdb.cp/ambiguous.exp was also changed to test for this
behavior.
gdb/ChangeLog:
PR gdb/28480
* valops.c (struct_field_searcher::update_result): Improve
ambiguous member detection.
gdb/testsuite/ChangeLog:
PR gdb/28480
Pushed by Joel Brobecker <brobecker@adacore.com>
* gdb.cp/ambiguous.cc: Add code to permit ambiguous member testing.
* gdb.cp/ambiguous.exp: Add ambiguous member test.
(cherry picked from commit a41ad3474c)
The Rust compiler plans to change the encoding of a Rust 'char' type
to use DW_ATE_UTF. You can see the discussion here:
https://github.com/rust-lang/rust/pull/89887
However, this fails in gdb. I looked into this, and it turns out that
the handling of DW_ATE_UTF is currently fairly specific to C++. In
particular, the code here assumes the C++ type names, and it creates
an integer type.
This comes from commit 53e710acd ("GDB thinks char16_t and char32_t
are signed in C++"). The message says:
Both places need fixing. But since I couldn't tell why dwarf2read.c
needs to create a new type, I've made it use the per-arch built-in
types instead, so that the types are only created once per arch
instead of once per objfile. That seems to work fine.
... which is fine, but it seems to me that it's also correct to make a
new character type; and this approach is better because it preserves
the type name as well. This does use more memory, but first we
shouldn't be too concerned about the memory use of types coming from
debuginfo; and second, if we are, we should implement type interning
anyway.
Changing this code to use a character type revealed a couple of
oddities in the C/C++ handling of TYPE_CODE_CHAR. This patch fixes
these as well.
I filed PR rust/28637 for this issue, so that this patch can be
backported to the gdb 11 branch.
(cherry picked from commit 1c0e43634c)
The rhES5 build failed due to an upstream import a while back. The
bug here is that, while the 'personality' function exists,
ADDR_NO_RANDOMIZE is only defined in <linux/personality.h>, not
<sys/personality.h>.
However, <linux/personality.h> does not declare the 'personality'
function, and <sys/personality.h> and <linux/personality.h> cannot
both be included.
This patch restores one of the removed configure checks and updates
the code to check it.
We had this as a local patch at AdaCore, because it seemed like there
was no interest upstream. However, now it turns out that this fixes
PR build/28555, so I'm sending it now.
