freenode/#clasp - IRC Chatlog
Search
15:49:20
cracauer
the buildbot (for branch main) is still broken. How there is use of Frame_O before it is declared.
15:49:52
cracauer
../../src/main/clasp_gc_cando.cc:19508:40: error: invalid application of 'sizeof' to an incomplete type 'core::Frame_O'
16:15:39
Bike
any and all mentions of Frame_O should be deleted. i guess i missed some since they're only conditionally compiled, maybe?
16:17:56
Bike
i'd also like to rename the DebuggerFrame_O class to Frame_O, but it would be good to remove all mentions of the old class first
16:18:17
drmeister
The error message looks misleading so first I'll look for and remove all mentions of Frame_O
16:23:05
drmeister
Bike had too little data to come to the correct conclusion. There is no conditional compilation going on here. clasp_gc_cando.cc has a lot of things within it - one thing is a declaration of every class that was exposed.
16:23:25
drmeister
Bike removed Frame_O and I haven't rerun the static analyzer to rebuild clasp_gc_cando.cc
16:33:48
Bike
so if i do rename debuggerframe_O to frame_O that'll be another static analysis run. how inconvenient.
16:34:16
drmeister
It's ok, right now because we removed a class I just removed every reference to Frame_O
16:35:31
drmeister
We need to do a little work with the static analyzer and extensions to let them work together better.
16:36:30
Bike
by the way, i tried delecting the debug_unixes and debug_macosx files outright, but it caused some nasty early build failures. looks like there's stuff threaded through the startup code dealing with registering shared objects or something
16:38:46
Bike
terminology, you mean? i don't know. i just think "shared object" since i'm used to seeing .so files
16:39:33
drmeister
I'm starting to think that the static analyzer should generate a description of objects and their layouts rather than generate C++ code like it currently does. Then have the scraper fold the description of objects from the static analyzer into the C++ code that the scraper generates.
16:40:40
Bike
some kind of declarative description does sound preferable. easier to use if we need to change gc guts like for that rust thing
16:41:16
drmeister
I think it's historical - we register shared libraries at startup because we used to setup symbol tables at startup. Then I started to use the shared libraries list for other things like stackmaps and backtraces.
16:46:25
Bike
well the new debugger code doesn't do shared object stuff at all, it just goes through the regular objects
16:47:36
drmeister
Right - I think with snapshots and faso files we completely avoid C++ DWARF information.
16:49:08
drmeister
Regarding the static analyzer - if I switch to generating a description of classes then here's what we will get.
16:49:43
drmeister
If you run the static analyzer on cando you get a description of clasp&cando classes.
16:50:27
drmeister
If you added extension FOO you would run the static analyzer with just clasp and the FOO extension and you would get a description of clasp&FOO classes assuming FOO has exposed classes.
16:51:18
drmeister
If you then assembled a clasp+cando+FOO system the scraper would merge the clasp, clasp&cando, clasp&FOO descriptions into a clasp&cando&FOO description.
16:52:57
drmeister
This way we would have to run the scraper N times for N extensions but we could assemble them into any combination as long as they are all internally consistent.
16:53:33
drmeister
There are versioning issues with this. If your clasp description of a class doesn't match the clasp&cando description - then those two versions are out of sync.
16:54:24
drmeister
We can tolerate moving fields around and adding and removing POD fields from exposed classes. But it cannot tolerate adding or removing GC managed pointer fields.
21:29:06
drmeister
My guess is you were removing code from debug_macos.cc and got that working but didn't make corresponding changes to debug_unixes.cc - correct? I'm looking to carry out similar removal of code from debug_unixes.cc and I'd like to touch base with you as to what you did.
21:35:15
Bike
like i said, i wanted to just delete both of them entirely, but it takes a little more subtlety
21:39:14
Bike
the new debugger isn't using the registered shared objects in any way but removing that code outright doesn't seem to be enough maybe
21:41:16
drmeister
startup_register_loaded_objects is defined in both debug_unixes.cc and debug_macos.cc and it is called from main.cc
21:44:11
Bike
the new debugger code doesn't use anything in either debug_ file. it just gets the stackmaps through the object files
21:44:25
Bike
which go through the, what's it called, the AllObjectsLoaded variable or whatever it is
21:45:27
drmeister
dbg_safe_backtrace() - we call that from a couple of lonely places. We don't have that anymore - right?
21:47:19
drmeister
I'm going to define a stub for it in debugger.cc that will simply print a message and abort().
21:52:35
drmeister
There might be a role for a dbg_safe_backtrace - we would use it to dump a backtrace when things are going belly up and we want some idea of what happened.
21:53:24
drmeister
But there's another way we could go with this. backtrace(...) backtrace_symbols(...) and the GDB JIT API to recover the dwarf info
21:56:43
drmeister
What I'm still missing to understand how the gdb jit interface works is to know where the text section for each object file is loaded. That isn't defined in the gdb jit interface.
22:31:42
drmeister
Bike: How much code we can remove depends on what direction we are going with fasl files.
22:32:27
drmeister
1. faso/fasp files - these are lists of object files that are added to the JIT and they carry their DWARF with them - this is what we are currently using.
22:34:01
drmeister
2. .so/.dylib files - we can link all of the object files into a shared library and load that. This won't work with our current backtraces.
22:34:53
drmeister
3. We can use LTO to link all of the bitcode for C++ and Common Lisp and then turn that into a single executable. This has problems though - it doesn't work for quicklisp code - that needs 1 or 2.
22:35:48
drmeister
Backtraces as you have developed them won't work for 3 either until we add more code to handle shared library and executable DWARF.
22:36:42
drmeister
Option 3 could improve performance if we could figure out how to inline C++ into CL and vice versa.
22:37:29
drmeister
But I think we should go a different direction - I think we should go with (1) and for performance in the future we implement beach's call site optimization.
22:39:53
drmeister
::notify bike Could you take a look at the log - I'd like to talk about REDUCING our linking options which would allow us to remove code from debug_unixes.cc/debug_macos.cc . It would also mean turning agh
22:40:44
Colleen
Bike: drmeister said 50 seconds ago: Could you take a look at the log - I'd like to talk about REDUCING our linking options which would allow us to remove code from debug_unixes.cc/debug_macos.cc . It would also mean turning agh
22:41:31
drmeister
I've been keeping shared object/library linking alive because it's very similar to LTO.
22:44:11
drmeister
I implemented faso/fasp files a year ago because I wanted to try this experiment where we load object files into the JIT and link at load time.
22:44:48
drmeister
I think the result is that this works very well. It's fast and it looks like we can do it multicore and make it almost imperceptibly fast.
22:45:10
drmeister
Previous to this we were linking JITted code into .so/.dylib files and those were our .fasl files.
22:46:47
drmeister
Ah - we will still be able to load those - we just get their return address symbols using backtrace_symbols(...)