|
1938 | 1938 | DerivedClass, BaseClass, Offset)]).
|
1939 | 1939 |
|
1940 | 1940 | % An easier to understand version of E that builds on concluded VBTable facts instead of RTTI.
|
| 1941 | +reasonDerivedClass_F(DerivedClass, BaseClass, Offset) :- |
1941 | 1942 | reasonDerivedClass_F(DerivedClass, BaseClass, Offset) :-
|
1942 | 1943 | factObjectInObject(DerivedClass, BaseClass, Offset),
|
1943 | 1944 | % There's an entry in some VBTable somehere (only unified by Offset so far).
|
1944 |
| - factVBTableEntry(VBTableAddress, _TableObjectOffset, Offset), |
| 1945 | + factVBTableEntry(VBTableAddress, TableOffset, OffsetFromVBPtr), |
| 1946 | + % The first offset of a VBTable is the offset from the vbptr to the object start. |
| 1947 | + TableOffset > 0, |
1945 | 1948 | % And that VBTable is installed into an object in some Method.
|
1946 |
| - factVBTableWrite(_Insn, Method, _VBTableOffset, VBTableAddress), |
| 1949 | + factVBTableWrite(_Insn, Method, VBPtrOffset, VBTableAddress), |
| 1950 | + % Ensure that BaseClass is not empty. If it is, there could be multiple |
| 1951 | + % classes at the same offset. |
| 1952 | + notEmptyClass(BaseClass), |
1947 | 1953 | % Finally, check that the method is assigned to the Derived class.
|
1948 | 1954 | % This is the unification that makes the VBTableEntry relevant.
|
1949 | 1955 | find(Method, DerivedClass),
|
| 1956 | + |
| 1957 | + % ejs 8/13/22 The offsets in a vbtable are offsets from the location of the vbptr, not from |
| 1958 | + % the beginning of the class. Sometimes the vbptr is at offset zero, but not always. |
| 1959 | + Offset is OffsetFromVBPtr + VBPtrOffset, |
| 1960 | + |
1950 | 1961 | % Debugging
|
1951 | 1962 | logtraceln('~@~Q.', [not(factDerivedClass(DerivedClass, BaseClass, Offset)),
|
1952 | 1963 | reasonDerivedClass_F(DerivedClass, BaseClass, Offset,
|
|
0 commit comments