clasp-developers
section table goes past the end of file
This was first seen in the regression tests when the system-construction.lisp BEFORE the debug.lisp file.
The system-construction.lisp compile-files "regression-tests;framework.lisp" and that appears to change the in memory object file so that when backtraces are generated in debug.lisp when a DWARFContext is built for a backtrace frame for a framework.lisp function it fails in building the object file.
This is pretty convoluted. But the object files are stored in memory in llvm::object::MemoryBuffer and I think the MemoryBuffer is being reused by llvm during the compile-file-parallel of framework.lisp in system-construction.lisp and overwritten.
I tried to mprotect the memory containing object files but that doesn't catch when the object file memory is written into. It's clearly changing though... when I invoke debug.lisp BEFORE system-construction.lisp it works fine. After system-construction.lisp it fails.
To debug this it helps to implement a no-handler-case-load-if-compiled-correctly function that doesn't wrap everything in a handler-case.
You can catch the rewrite of the object file by setting a watch point on a word in the object file...
Above is a dump of the first words of the framework.lisp object file when I dumped the framework.fasp"@21-21 object file after it is first compile-file-parallel'd (left) and after the system-construction.lisp file evaluates and compile-file-parallel's it again.
If from gdb/udb I use: watch *0x7feb9c7740b0 I can trap the second time framework.lisp is compile-file-parallel'd. I think this is when the problem starts.
I calculated the crc32 for the framework.fasp"@21-21 after the first time framework.lisp is compile-file-parallel'd and after it is compile-file-parallel'd and the crc32 changes after the second time.
A bandaid is to move the system-construction.lisp regression test to the end. I implemented this so that regression tests don't fail.