freenode/#clasp - IRC Chatlog
Search
16:24:50
Bike
okay i have a setup where you can abort threads. neat. this also means sldb-quit actually works on errors signaled in threads other than the repl thread
16:50:00
drmeister
How is the signal recognized by the Common Lisp/C++ code - the same way it is now?
17:09:03
kpoeck
there are a lot of #+darwin in the wild, perhaps we can maintain that for compability
18:07:17
Bike
https://github.com/clasp-developers/clasp/commit/0107c53283ce71ad478dcd45854e38d5dd444770 ???
3:45:29
drmeister
Bike: Do we get debug info on variables from DWARF? I know we are having issues figuring out what Common Lisp variables to generate DWARF for - but we could get C++ variables.
3:47:20
drmeister
Something that happens to me all the time - like now - is I have a bug in the C++ code and I'm trying to debug it from within Slime.
3:47:41
drmeister
The DWARF won't care. We give it an address and it should give us back what variables are available.
3:50:41
drmeister
Frame 47: __ZN4chem12RingFinder_O13vertexForAtomEN7gctools9smart_ptrINS_6Atom_OEEE
3:51:38
drmeister
Now that call-with-variable-bound and funwind-protect are gone (thankyou thankyou thankyou) it might make sense to put the C++ frames back in there.
3:53:05
drmeister
(core:maybe-demangle "_ZN4chem12RingFinder_O13vertexForAtomEN7gctools9smart_ptrINS_6Atom_OEEE")
3:53:59
drmeister
We know the return address for the "chem::RingFinder_O::vertexForAtom(chem::Atom_sp)" frame - we can ask for the source info and the variables that are available.
3:56:43
drmeister
For debugging I can recompile iclasp-boehm and add __attribute__((optnone)) to any function that I want to see the lexical variables and arguments.
4:02:47
drmeister
We could though - suppressing non-CL frames was important when we had call-with-variable-bind and funwind-protect. Now it makes more sense to show the C++ frames.
4:08:48
drmeister
https://llvm.org/doxygen/classllvm_1_1DWARFContext.html#a3dc5679c9f87dbde396b2ef8e006bc14
4:09:55
Bike
and then from the DILocal you get the FrameOffset, which is where the value is in the frame? i guess?