You should be able to directly debug in visual studio. Build and run lli with your hw-m32.ll added to the debug args. Make sure you do a debug build. The assert should cause the visual studio debugger to break and you can examine the call stack and figure out relevant breakpoints to set.
I found something, a real difference between the log in 32 arch and the log in 64 arch by running
- lli.exe -debug hw-m32.ll > lli-hw-m32.log 2>&1
- lli.exe -debug hw-m64.ll > lli-hw-m64.log 2>&1
In the 32 case, there is a undefined symbol: ErrorStr “Symbol not found: ___acrt_iob_func” std::string, and in fact, the symbol ‘_acrt_iob_func’ (with 3 '’ before) does not exist in the C:\WINDOWS\SYSTEM32\ucrtbased.dll, but there is a ‘__acrt_iob_func’ (2 '’ before) symbol exported.
The other strange thing is that in the lli-hw-m64.log, there is never a ‘___acrt_iob_func’ but only ‘__acrt_iob_func’ references and the lli 64 execution is working fine. And the assert below
uint8_t *getAddressWithOffset(unsigned OffsetBytes) const {
assert(OffsetBytes <= AllocationSize && “Offset out of bounds!”);
return Address + OffsetBytes;
}
is failing around solving a relocation of ‘___acrt_iob_func’ in the section 4. Thus, I am suggesting that solving the undefined issue on ‘___acrt_iob_func’ should solve the issue
The llvm::RuntimeDynldCOOF is too much complex for me to jump into. To whom, I could submit those informations for a fix?