dwblaikie wrote:
> FYI: There is already VTable support in our lldb::SBValue class and it is
> part of the public API in LLDB and doesn't require any of this:
> ...
> Doesn't require any debug info.
Does this/can this be used to determine the type of an object that points to
that vtable, though? If so, how does lldb resolve the ambiguities discussed
earlier in this PR? (it'd be great to find out there's a way to do this, but
it's not clear if/how that can be done - so more details about how lldb does
it, if it does, would be super interesting!)
Looks like it fails under ambiguity:
`test.h`
```
struct base {
virtual ~base() { }
int i = 3;
};
base* f1();
base* f2();
```
`test.cpp`
```
#include "test.h"
namespace {
struct derived: base {
float f = 3.14;
};
}
base* f1() {
return new derived();
};
void breakpoint() { }
int main() {
base* b1 = f1();
base* b2 = f2();
breakpoint();
}
```
`test2.cpp`
```
#include "test.h"
namespace {
struct derived: base {
long l = 42;
};
}
base* f2() {
return new derived();
}
```
```
$ lldb ./a.out
(lldb) b breakpoint
(lldb) r
(lldb) up
(lldb) v *b1
(derived) *b1 = {
base = (i = 3)
f = 3.1400001
}
(lldb) v *b2
(derived) *b2 = {
base = (i = 3)
f = 0
}
```
The latter should have a member named `l`, not `f` (with a different value too,
but I assume that's just from interpreting the long bitpattern as a float).
gdb fails in the same way:
```
(gdb) p *b1
$1 = ((anonymous namespace)::derived) {
<base> = {
_vptr$base = 0x555555557d20 <vtable for (anonymous namespace)::derived+16>,
i = 3
},
members of (anonymous namespace)::derived:
f = 3.1400001
}
(gdb) p *b2
$2 = ((anonymous namespace)::derived) {
<base> = {
_vptr$base = 0x555555557d88 <vtable for (anonymous namespace)::derived+16>,
i = 3
},
members of (anonymous namespace)::derived:
f = 0
}
```
If you actually debug into the derived type (add a virtual function, call it in
main, step into it from there in the debugger) lldb still thinks the type of
derived is the float version, even when you're in the long version - gdb at
least shows you the long version from inside, even though it continues to show
you the float version from outside.
==================================================
Unrelated to this discussion on vtables, I was curious about some related
local-type-naming-collision things:
if you remove the virtuality from it, lldb always thinks "derived" names the
type in the main file, even when you're in the context of test2.cpp. lldb
correctly follows type links (so if you print a local variable of "derived*" in
test2.cpp, it prints the long version), but not naming the type in the
expression evaluator, it seems.
```
(lldb) n
Process 2958937 stopped
* thread #1, name = 'a.out', stop reason = step over
frame #0: 0x00005555555552d4 a.out`s2(b=0x000055555556b2d0) at
test2.cpp:12:3
9 }
10 void s2(base* b) {
11 derived* d = (derived*)b;
-> 12 breakpoint();
13 }
(lldb) p *d
(derived) {
base = (i = 3)
l = 42
}
(lldb) p *(derived*)b;
(derived) {
base = (i = 3)
f = 0
}
```
(whereas gdb does get this ^ right, naming the type finds the appropriate local
one - and gdb rejects using the name in a context it doesn't apply, whereas
lldb will resolve the name in files that don't have this file-local name (seems
to resolve it to whichever instance of the name comes first in the DWARF))
https://github.com/llvm/llvm-project/pull/130255
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
