clayborg wrote: > Looks good in general to me. > > Several scenarios to test: > > * Make sure command works when the vtable symbol can be found but the vtable > exists in another binary which do not have any debug info (which we have seen > failure from lldb before)
Good idea. I tried to test by stripping, but then I couldn't set a breakpoint where I needed it. So if we do this in another binary and just strip the shared library, then I can test this. > * Is vtable pointer guarantee to be in the first pointer of object? Yes, if the value is polymorphic. We make sure the type has virtual functions first before doing any of this. > * Can we test this during multiple inheritance? Should we print multiple > vtables? I can add a test for this and make sure things works when dynamic typing is on and off. We won't print multiple vtables, as each class has only 1 vtable, it will just include all of the virtual methods needed for any inherited classes. > * Test in coredump to make sure it works That is tricky due to the vtables never being stored in the core files since they are in read only sections. https://github.com/llvm/llvm-project/pull/67599 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
