libera/#clasp - IRC Chatlog
Search
13:28:45
Bike
well, i'm still staring at the analyzer code for it, but i can maybe just figure it out
13:29:06
Bike
if i want to use both the analyzer sif and the other sifs i guess i'll have to figure out how to correlate the names, since they work differently between them
13:40:03
Bike
i'd have to use the STAMP-KEY, which is "gctools::GCVector_moveable<core::T_O *>" for example
13:42:19
drmeister
Are you talking about correlating names from the scraper to the ones from the static analyzer?
13:42:55
drmeister
If so I'd say don't bother. The static analyzer gives a more complete view of the classes than you get from scraping the LISP_CLASS macros.
13:43:53
drmeister
You will need to correlate names from one static analyzer generated sif to another - but they will be identical.
13:45:34
Bike
well, i was thinking of the stuff we were talking about where was verify that the info from both matches
14:12:17
drmeister
I haven't put the time into the lldb extension. I put a lot of time into udb and udb doesn't work with this code.
14:13:04
drmeister
udb doesn't work with jitted code - it takes forever to startup. As in I've never seen cando startup under udb
14:13:42
drmeister
So I've got to put time into the lldb external debugging interface to get it working.
14:16:38
drmeister
gdb has become useless to me over the last couple of months and so has udb because it's built on gdb.
14:17:31
drmeister
On linux, however, lldb and llvm have developed the ability to see source code of jitted code.
14:18:11
drmeister
Meanwhile ccando-boehmprecise is crashing while it's starting up. It's crashing very, very deep in ASDF.
14:20:03
drmeister
The gdb/udb problem is something to do with the jit code registration facility. gdb is too eager and it gets bogged down.
14:26:58
Bike
yeah, it's truename signaling an error, which i think will mostly happen if the file doesn't exist
14:28:29
Bike
course that doesn't help much if you can't get the pathname. i guess subdir might be it
14:31:51
Bike
i think at this level it's pretty much calling posix functions, which are case sensitive unless i'm mistaken
14:43:54
drmeister
But that's not on the stack. I know I reported that above (and forgot about it). The stack doesn't show any recursion.
14:44:29
Bike
if you hooked in the debugger before the error is signaled, you hit the breakpoint on lisp_error, rather than the later segfault
14:45:06
attila_lendvai
ACTION has a vague memory of porting his nested error handling from sbcl to clasp. it may have been a forgotten PR, or merely a plan...
14:45:06
Colleen
attila_lendvai: drmeister said at 2021.06.01 15:36:39: I think Clasp is an excellent tool to work with LLVM - it won't be completely safe though - expect segfaults because you can do things with LLVM in C++ memory that aren't safe. Clasp is currently up to date with LLVM13 tip-of-trunk as of about two months ago.
14:52:52
drmeister
I'll get the lldb extension working again and then at least I can print objects again.
14:58:35
Bike
hm, well it's in uiop/whatever:subdirectories, which is supposed to be looking through the filesystem for subdirectories of a given directory
15:01:18
drmeister
I might as well be peering through racks of vacuum tubes looking for a burned out one.
15:03:10
drmeister
I'll get the lldb extension working. It's all the same code as for the udb/gdb extension except for the interface to lldb - that's certainly where the problem is.
15:03:46
drmeister
With lldb on linux we have source level debugging - that's good. But there are very, very few arguments available.
15:04:11
drmeister
It's all: frame #334: 0x00007fffc79896ab JIT(0xfabf000)`QUICKLOAD^QUICKLISP-CLIENT^(closure=<unavailable>, nargs=<unavailable>, farg0=<unavailable>, farg1=<unavailable>, farg2=<unavailable>, farg3=<unavailable>) (T))^METHOD^^
15:04:22
drmeister
<unavailable> <unavailable> <unavailable> <unavailable> <unavailable> <unavailable>
15:05:48
drmeister
Otherwise what I do is dump registers and look for anything that is tagged and inspect that tagged pointer.
15:09:17
SAL9000
drmeister: FYI, this might be a useful tool for some of your debugging scenarios (not necessarily *this* one, though) http://www.jemarch.net/poke
15:11:13
drmeister
SAL9000: That is helpful. My lldb/gdb extension does something like that for binary data within memory.
15:11:42
drmeister
But say I want to interpret my snapshot files - that poke thing would be useful because I could describe my object in 'poke' format.
15:12:12
SAL9000
there was some work on inspecting processes like a debugger does, too -- don't recall whether it's been released yet
15:12:57
drmeister
Bike: Those 999905 line numbers show up a lot. We compile hundreds of thousands of lines of code - but from the debuggers point of view a surprising number of them are line number 999905
15:13:25
SAL9000
it's the first "smart hex editor" tool that I've tried which can handle Göran's crazy custom data structures :-)
15:18:12
drmeister
I'm working on generating a docker container to get this DNA encoded library analysis stuff to a collaborator and here I am debugging low level stuff and looking at bytes in memory.
15:18:19
Bike
hm, well that will cover the main call but maybe it's also used in ensure-origin, which comes up in various places