|
1941 | 1941 | reasonDerivedClass_F(DerivedClass, BaseClass, Offset) :-
|
1942 | 1942 | factObjectInObject(DerivedClass, BaseClass, Offset),
|
1943 | 1943 | % There's an entry in some VBTable somehere (only unified by Offset so far).
|
1944 |
| - factVBTableEntry(VBTableAddress, _TableObjectOffset, Offset), |
| 1944 | + factVBTableEntry(VBTableAddress, TableOffset, OffsetFromVBPtr), |
| 1945 | + % The first offset of a VBTable is the offset from the vbptr to the object start. |
| 1946 | + TableOffset > 0, |
1945 | 1947 | % And that VBTable is installed into an object in some Method.
|
1946 |
| - factVBTableWrite(_Insn, Method, _VBTableOffset, VBTableAddress), |
| 1948 | + factVBTableWrite(_Insn, Method, VBPtrOffset, VBTableAddress), |
1947 | 1949 | % Finally, check that the method is assigned to the Derived class.
|
1948 | 1950 | % This is the unification that makes the VBTableEntry relevant.
|
1949 | 1951 | find(Method, DerivedClass),
|
| 1952 | + |
| 1953 | + % ejs 8/13/22 The offsets in a vbtable are offsets from the location of the vbptr, not from |
| 1954 | + % the beginning of the class. Sometimes the vbptr is at offset zero, but not always. |
| 1955 | + Offset is OffsetFromVBPtr + VBPtrOffset, |
| 1956 | + |
1950 | 1957 | % Debugging
|
1951 | 1958 | logtraceln('~@~Q.', [not(factDerivedClass(DerivedClass, BaseClass, Offset)),
|
1952 | 1959 | reasonDerivedClass_F(DerivedClass, BaseClass, Offset,
|
|
0 commit comments