use RTTI inheritance data about pharos HOT 9 CLOSED

Actually, I confirmed recently that this does work in at least some circumstances. In the case that caused me to investigate, it was because we had deemed the RTTI information invalid during initial analysis resulting in it being discarded entirely. Can you investigate a little more and confirm that this is not happening? The restrictions on "valid" RTTI are currently too tight I think.

Alternatively, a small subset of the facts that demonstrate the problem in Prolog would be helpful. Now that there's improved logging in the Prolog phase, hopefully you'll be able to narrow the problem down to a Prolog based test case. If that's not convenient, another godbolt example to demonstrate the problem should be sufficient for us to investigate.

from pharos.

I'll check. Also discovered it incorrectly merged an abstract base class (interface) with one of its descendants because it concluded the subclass had no base.

from pharos.

Determining conclusively whether a class has a base class or not is nearly impossible. It's one of the primary "facts" that the Prolog phase is required to "guess" in order to be able to reason forward soundly about other facts. RTTI information can imply the lack of base class based on the reasoning that it would have been listed in the RTTI structures if it had existed, and this is a significant benefit from having RTTI. Point is: this kind of failure is among the most difficult to prevent in OOAnalyzer. If you have suggestions on how you would have concluded that there was a base class, we'd like to hear about it. :-)

from pharos.

Alternatively, a small subset of the facts that demonstrate the problem in Prolog would be helpful. Now that there's improved logging in the Prolog phase, hopefully you'll be able to narrow the problem down to a Prolog based test case. If that's not convenient, another godbolt example to demonstrate the problem should be sufficient for us to investigate.

Tried to create a small test case but it's not all that good I guess:
https://godbolt.org/z/mOcOpa
It does read the RTTI data but I don't see it being used.
Here are the original prolog facts, rtti entry 0x6be400.

from pharos.

@sei-ccohen It looks like we aren't detecting the inheritance through RTTI because of the following check in rTTIInheritsDirectlyFrom:

rTTIBaseClassDescriptor(BCDA, AncestorTDA, _NumBases, M, P, V, 0x40, _ECHDA),

I can't find any documentation for the attributes field, which you are checking is 0x40. None of the entries in this example have the attributes value 0x40. Is there a particular reason or meaning for 0x40?

from pharos.

I think I found the meaning of 0x40: https://www.unknowncheats.me/forum/938170-post9.html

If BCD_HASPCHD, then the BaseClassDescriptor has an extra pointer(32 bit/64 bit respectively) trailing the structure which is a pointer to the ClassHiearchyDescriptor.

It's still unclear why we would need this...

from pharos.

After fixing several issues (internally) in RTTI validation and reporting, I've tracked the problem back to some missing RTTITypeDescriptor facts at addresses 0x69f0c0 and 0x6bcc28. Because our RTTI fact exporting is currently based on VFTable detection, I suspect that something has gone wrong while detecting VFTables. Unfortunately, it's difficult to debug fact exporting from the exported facts. ;-)

Can you please provide the executable as well, so that we can continue to investigate? The solution might require a change in how we approach RTTI facts (hard) or a minor fix to VFTable detection (easy).

from pharos.

I tested this executable to see how it works when RTTI data is available.

from pharos.

I believe this is fixed in 90f9011. Reopen if not.

from pharos.