freenode/#clasp - IRC Chatlog

22:56:51 drmeister Hi

22:57:02 drmeister Hi

22:58:18 drmeister I'm not sure. On linux it's a static constructor that shouldn't be needed but is being invoked because I'm including clasp headers that declare it.

22:58:57 drmeister Static constructors are getting a big refresh by llvm11 - but that's not ready yet.

22:59:16 drmeister Another idea would be to compile and link the code with Clasp and load the dynamic library.

23:00:45 paulapatience[m] Compile and link the cxx code with clasp rather than clang, you mean? Clasp can do that?

23:03:13 drmeister No - I mean link the demo with the clasp code.

23:03:44 drmeister Right now we are taking a short-cut. We are compiling the demo code to bitcode. The .bc file in each directory

23:04:36 drmeister Clasp knows how to load it's own bitcode files.

23:05:25 drmeister Here we are kind of spoofing that. We are compiling a C++ file to bitcode and making it look like a clasp generated bitcode file. But it's not a perfect spoof because we compile C++ header files that are declaring static initializers.

23:05:28 drmeister Thinking...

23:06:19 drmeister When we load the bitcode into clasp it compiles the bitcode to native code and links it against symbols that are already loaded.

23:06:27 paulapatience[m] I see

23:06:31 drmeister That's not working properly, some symbols are not linking. That's confusing me.

23:07:02 drmeister Maybe it's the code model. Maybe the symbols are more than 2GB away and they can't be linked?

23:07:36 drmeister The linux JIT linker is being rewritten as we speak. By llvm11 this will be a lot easier.

23:07:54 drmeister They are making the JIT linker work very much like the system linker. Right now everything is hacked together.

23:08:26 drmeister That's my understanding. But it's informed by long discussions with Lang Hames - the developer of the new ORC JIT.

23:08:53 drmeister Let's try changing the code model.

23:13:04 paulapatience[m] ACTION sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/umdQtPUqjIZDjoLWKCOVkbUd >

23:13:13 drmeister Grr - how do I change the code model from the command line?

23:13:46 paulapatience[m] I don't know if that means it's 2 GB away though

23:13:52 drmeister I think it's actually a call instruction right before that.

23:14:01 drmeister Do you see a: call $rax?

23:14:16 drmeister Go: info registers and check what $rax is

23:14:58 drmeister Here's what I have...

23:14:59 drmeister https://www.irccloud.com/pastebin/xPCEcZy3/

23:15:12 drmeister First a disassembly and then the registers.

23:15:35 drmeister The return address on the stack points to the next instruction.

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:16:36 drmeister I look for the frame just before the segfault.

23:17:06 drmeister Here's more context...

23:17:07 drmeister https://www.irccloud.com/pastebin/eCvtzvH3/

23:17:15 drmeister Frame #56

23:17:26 drmeister __cxx_global_var_init.14 is a global ctor

23:17:51 drmeister Note this...

23:17:52 drmeister 0x00007f8f3e020e77 <+55>: movabs $0x0,%rax

23:18:53 paulapatience[m] ah let me try in gdb

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:19:10 drmeister I use gdb on linux and lldb on macOS.

23:19:14 drmeister I'm getting pretty flexible.

23:20:07 drmeister There

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:21:44 drmeister I know like five gdb commands and ten lldb commands and that's how I get by.

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:23:32 paulapatience[m] ok I'm seeing the same disassembly as you in gdb

23:25:04 paulapatience[m] yeah i agree it's weird to call rax right after zeroing it

23:25:14 drmeister That'

23:25:33 drmeister That's why I think the problem is linking. The linker should be putting an address in there.

23:35:27 drmeister This is what that function looks like in llvm-ir...

23:35:36 drmeister https://www.irccloud.com/pastebin/ybayhGHF/

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:37:17 drmeister The second call that is to 0x0 is: reg::allocate_class_id(reg::type_id const&)

23:37:20 drmeister The first one is...

23:38:10 drmeister reg::type_id::type_id(std::type_info const&)

23:38:29 drmeister Why does it link one and not the other? Dunno.

23:38:38 drmeister Is it a linking problem? Also dunno.

23:40:43 paulapatience[m] Ok those are the functions that we should be calling but that are called as 0 instead?

23:41:44 drmeister I believe the reg::allocate_class_id(reg::type_id const&) function is 0x0

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:42:22 drmeister In the llvm-ir there are two calls one right after the other.

23:45:17 paulapatience[m] Yeah the first call is to reg::type_id(std::type_info):

23:45:17 paulapatience[m] (gdb) x 0x7ffff7fb9720

23:45:17 paulapatience[m] 0x7ffff7fb9720 <_ZN3reg7type_idC2ERKSt9type_info>: 0xe5894855

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:47:48 drmeister https://www.irccloud.com/pastebin/kjS2i3MZ/

23:48:04 drmeister A bunch of them are 00000000

23:56:21 paulapatience[m] I'm getting 0s for a bunch of other functions too, though. Is that normal?

23:56:54 paulapatience[m] http://ix.io/2gGz

23:57:18 paulapatience[m] registered_class among others

0:00:34 paulapatience[m] ah but they're weak object symbols

0:00:45 drmeister I don't know.

0:01:05 paulapatience[m] i think they get overridden when linking

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:05:37 drmeister Here's what I get on linux...

0:05:39 drmeister https://www.irccloud.com/pastebin/kS6VJPt8/

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:09:58 paulapatience[m] indeed

0:19:00 drmeister On macOS I can step into the startup function and there are no $0x0 being called.

0:19:27 drmeister I'm not sure that this is the problem - but here's what I think is going on.

0:20:13 drmeister I depend on static initializers to setup the code that exposes C++ functions.

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:22:27 drmeister llvm has been changing a lot.

0:22:30 paulapatience[m] Linking is the only way to expose a C++ library to CL, right?

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:26:15 paulapatience[m] Hmm, I suppose in the meantime I could try it on freebsd

0:34:35 drmeister I'm looking at the code that does this - it's pretty simple.

0:34:36 drmeister https://github.com/clasp-developers/clasp/blob/dev/src/llvmo/llvmoExpose.cc#L3182

0:34:56 drmeister engine->runStaticConstructorsDestructors(false);

0:35:06 drmeister That's where it's failing when it runs static constructors.

0:40:06 drmeister I'm trying to figure out why it used to work but doesn't work now.

0:40:25 drmeister One thing I'm doing is calling setUseOrcMCJITReplacement(true);

0:40:48 drmeister That's using the new ORC JIT engine and I know that is under heavy development.

0:48:34 drmeister I tried disabling that - but it still doesn't work.

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.

1:28:45 drmeister Also, our static initializer is also broken with lots of calls to $0x0 on linux

1:28:55 drmeister The runtime linking appears to be broken.

1:29:15 drmeister I've put in a question to the llvm ORC JIT developer on discord.

1:29:28 drmeister He usually gets back to me in a day or two.

1:29:37 drmeister I don't understand why this worked before but not now.

1:29:56 drmeister Esspecially when I disable setUseOrcMCJITReplacement setUseOrcMCJITReplacement

1:30:01 paulapatience[m] Ok

1:30:13 drmeister My keyboard iss crap and reppeatsss keys like crazy.

1:30:23 drmeister I've given up trying to clean it up.

1:30:24 paulapatience[m] I hate when that happens

1:30:29 paulapatience[m] (to me)

1:30:35 drmeister MacbookPro

1:31:00 drmeister I'll check with Lang to see what's going on with static constructorss.

2:23:43 drmeister https://www.irccloud.com/pastebin/1d3AwRDz/

2:23:55 drmeister I'm having a problem with recursion - I think I'm missing out.

2:24:14 Bike well, your patch-object function doesn't do any recursion

2:25:07 drmeister Right - so what kind of recursion does it need to do?

2:25:23 Bike it needs to call fixup on value-old if found-p is false, as we discussed earlier

2:26:03 drmeister Did we discuss that?

2:26:38 Bike yeah, around one o clock

2:27:28 Bike so what is passed to make-record-patcher in circle-subst now?

2:31:12 Bike fixup is called for effect, so it just needs to call fixup on value-old before returning it

2:34:34 drmeister https://www.irccloud.com/pastebin/jzRoNnHX/

2:34:37 drmeister How about that?

2:34:50 Bike no, fixup will return nil or something

2:34:51 drmeister After I take out the format statements.

2:34:59 Bike do (progn (fixup ...) value-old)) or so

2:35:16 drmeister fixup isn't allowed to return anything?

2:35:27 Bike more like it doesn't have to return anything meaningful.

2:36:06 drmeister Ok, this for patch-object?

2:36:07 drmeister https://www.irccloud.com/pastebin/tlq41n3T/

2:36:20 Bike i think that will be better, yeah.

2:37:46 drmeister That does the trick.

2:38:03 drmeister Here's the code...

2:38:05 drmeister https://www.irccloud.com/pastebin/rIPSTsGZ/

2:38:37 Bike still think make-record-patcher should only get the closure, though

2:45:38 drmeister The C++ code only needs the mapping and I can't create a closure from C++.

2:46:55 Bike why does the C++ code need the mapping?

2:47:00 Bike doesn't it just pass it as an argument to the function?

2:47:20 drmeister circle-subst takes the mapping and the object.

2:47:52 Bike you could just pass (lambda (object) (circle-subst object mapping)) to make-record-matcher

2:48:02 Bike or whatever the argument order is, you know what i mean

2:48:25 Bike i say this because this mapping mechanism could have uses outside of ## patching

2:51:36 drmeister Hmmm.

2:51:46 drmeister But do I create patching objects from C++.

2:52:03 Bike really? for what?

2:52:13 drmeister I'm checking if I do...

3:11:27 drmeister Rebuilding everything now.

3:11:38 drmeister I set it up to just use the closure.

3:53:33 beach Good morning everyone!