freenode/#clasp - IRC Chatlog
Search
23:16:08
paulapatience[m]
what command did you run to get that output? I can't seem to get the disassembly around frame #1
23:18:59
drmeister
It's putting 0x0 in %rax and then calling it two instructions later - that's crazy. So it makes me think the $0x0 should be an address that failed to link.
23:20:20
paulapatience[m]
I naively assumed that since we compile clasp with llvm we should debug it with lldb
23:20:28
drmeister
There's nothing wrong with calling 0x0 - until you get there and hit a page fault.
23:21:01
drmeister
Sure - but lldb needs to be installed on linux and I often don't take the trouble.
23:23:09
paulapatience[m]
I used to use gdb a lot when debugging microcontrollers a few years ago, but it's the kind of stuff you forget from lack of use...
23:25:33
drmeister
That's why I think the problem is linking. The linker should be putting an address in there.
23:35:49
drmeister
call void @_ZN3reg7type_idC2ERKSt9type_info(%"class.reg::type_id"* %1, %"class.std::type_info"* dereferenceable(16) bitcast (i8** @_ZTIN4core6Real_OE to %"class.std::type_info"*))
23:35:57
drmeister
Followed by %5 = call i64 @_ZN3reg17allocate_class_idERKNS_7type_idE(%"class.reg::type_id"* dereferenceable(8) %1)
23:40:43
paulapatience[m]
Ok those are the functions that we should be calling but that are called as 0 instead?
23:42:11
drmeister
There are only two calls, the first one seems to be to a reasonable address, the second one to 0x0
23:47:46
drmeister
Here's something interesting. When I compile it to an object file. A bunch of __cxx_global_var_init.xxx functions don't appear to generate code.
23:56:21
paulapatience[m]
I'm getting 0s for a bunch of other functions too, though. Is that normal?
0:01:49
paulapatience[m]
but the cxx_global_var_init ones are in the text section so I would imagine they don't get overridden. but i do not have much experience in this.
0:02:39
drmeister
I disassemble the startup function and it's full of 0x0 - it isn't linking at all.
0:06:41
drmeister
Lines 9, 14, 54 - You can search for $0x0,%rax and then see a call to *$rax right after that.
0:21:22
drmeister
I think the linking on linux is going to be broken until the JITLinker is completed for linux in llvm11
0:22:10
drmeister
I had this stuff working on linux at one point - but it's the hardest stuff to keep working - even though it's a signature feature of clasp.
0:23:42
drmeister
When we load bitcode - it needs to link the addresses in the native code generated from the bitcode to symbols in the executable - yes.
0:24:09
drmeister
We could use the system linker - but then we need to generate a clasp dynamic library to link against - we don't have that. We generate a clasp executable.
0:51:46
paulapatience[m]
You mentioned that the static initializers are already initialized when we call runStaticConstructorsDestructors (if I understood correctly). Would it be possible to disable the reinitialization somehow?
1:28:15
drmeister
No - because our static initializer is in the list of static initializers. It's just that we picked up a bunch more from header files.
2:31:12
Bike
fixup is called for effect, so it just needs to call fixup on value-old before returning it
2:47:52
Bike
you could just pass (lambda (object) (circle-subst object mapping)) to make-record-matcher
6:29:35
kpoeck
Loading #P""/Users/karstenpoeck/lisp/compiler/clasp-karsten/build/boehm/fasl/aclasp-boehm-bitcode/src/lisp/kernel/lsp/defstruct.faso""