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.