Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
00:11 mst left, mst joined 00:15 MasterDuke joined
MasterDuke very apropro that github.com/zherczeg/sljit showed up on HN today 00:16
03:24 Nicholas left, Nicholas joined
timo1 gist.github.com/timo/0732287704e94...e9aecb12b7 - got a nice surprise / puzzle for you. tell me, what do you see? :D 05:51
07:22 ilogger2 left, ilogger2 joined 07:55 sena_kun joined 10:31 MasterDuke left
Geth MoarVM/main: 69368605f3 | (Daniel Green)++ | azure-pipelines.yml
Update MacOS versions in Azure CI config

Use newest versions as default and name the older available versions.		 10:41
MoarVM/main: c5cc940132 | MasterDuke17++ (committed using GitHub Web editor) | azure-pipelines.yml
Merge pull request #1820 from MasterDuke17/update_os_versions_in_azure_ci_config
10:43 brrt joined
brrt \o 10:43
lizmat brrt o/
timo1 hey brrt hey brrt hey brrt check this out: gist.github.com/timo/0732287704e94...e9aecb12b7
brrt checking... 10:50
context? 10:51
timo1 #1 0x00007ffff763da29 in MVM_frame_dispatch (tc=0x3d932020180, code=<optimized out>, args=..., spesh_cand=<optimized out>) at src/core/frame.c:591 10:52
#2 0x00007ffff58e8837 in parse-thing ()
#3 0x00007ffff762f783 in MVM_interp_run (tc=<optimized out>, initial_invoke=<optimized out>, initial_invoke@entry=0x7ffff775b4a0 <toplevel_initial_invoke>,
do you see what this is? :D
brrt yes, I see it, we're invoking the trampoline and trying to assign to the return address, but where is the intermediate JIT frame 10:53
oh, you mean, this has the name of the raku function?
timo1 compare this to the sad state before What I Did
#4 0x00007ffff76699e1 in MVM_gc_allocate_nursery (tc=0x32500020180, size=40) at src/gc/allocation.c:37
#5 0x00007ffff58e64f6 in ?? ()
#6 0x0000032500455360 in ?? ()
(this is obviously not from the same execution) 10:54
brrt ah, I see
that's very nice
timo1 isn't it! :D
brrt by the way, why is it a sigint
how did you do it
is the sigint intentional?
timo1 i pressed ctrl-c in gdb
brrt :D
ah
gotcha
so this isn't a bug in the jit trampoline
timo1 correct 10:55
brrt *phew*
timo1 though i'm not 100% sure the "finish" did its thing correctly
so now that i've lifted the secret i can start explaining
this uses the "jit reader" functionality in gdb: you tell gdb to "jit-reader-load /home/bla/bla/moar-jit-reader.so" 10:56
and your program has to fill some datastructures and call an empty function that gdb puts a breakpoint in for you automatically 10:57
so like: compiling a jit frame to native code in the region from 0x00007ffff58e8000 to 0x00007ffff58e8000 + 5000 or whatever; then you create a "symbol file" which you are free to put whatever data you like into 10:58
in my case the "symbol file" just has the address of the MVMJitCode struct + line number and file name for convenience 10:59
that + the sizeof the struct and the extra data is put into a jit_code_entry, which then causes gdb to copy the data from the target program into the memory that your jit reader .so file has direct access to, and then you can ask gdb to copy data from other addresses in the target program into your memory, and also for unwinding to get the values of registers in a frame (including what was saved on 11:02
the stack) and to set the values of registers "before your frame" so it can actually unwind
so what i have to do is get the rbp, the base pointer, from which i can offset to get TC, CU, Work, the previous frame's RIP, RSP, and RBP with some amount of indirection that i struggled to figure out 11:04
i can't call code that runs inside the target process so i can't just MVM_string_utf8_encode_c_string, so i have a crappy half implementation of string encoding that currently can't handle strands :D
brrt but it's still very nice 11:15
that's been somehthing that we've been thinking about for... years
awesome work 11:16
timo1 SMOP :)
in order to get perf to be able to sample into and annotate jit frames there's yet another format we have to support :) :) :)
i wanted to do the perf thing first but i got Distracted
as soon as i try to add line number info to the bytecode objects, i run into this: 11:17
../../gdb/objfiles.h:484: internal-error: sect_index_text not initialized 11:18
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
the jit reader makes it unnecessary to create a full ELF object for a compiled frame, but it's apparently not quite as battle-tested against inexperienced / bumbling implementors against the API 11:20
if i want to make variable names available, i may actually have to go to full ELF files with DWARF information after all. i don't see a way to do that from the jit-reader API at all 11:30
i also have some code commented out to split the frames by the labels, which are BB boundaries, but then doing "disassemble" gives you only the current BB, and it shows it as the "name" of the function (which is a decision i have to make, i'm free to choose what exactly to call it) 11:32
another thing i tried was to split frames into frame and frame_exit by the position of the exit label, which at least means the "data segment" doesn't show up as part of the disassembly with some "(bad)" instructions and a bunch of less sensible ones
yet another thing i've been wondering about is how to give gdb a hint what our indirect calls mean; it can already just show it like this: 0x00007ffff58e80c1 <+193>: call *0x232d(%rip) # 0x7ffff58ea3f4 <parse-thing+9204> 11:33
or with the _exit variant it's at least a tiny bit clearer that it's not using call as a strange way to jump around inside the frame itself
but i can't see a way currently to have gdb look at the content at that address and show immediately the name of the symbol it's going to call 11:34
11:39 rypervenche left 11:41 brrt left 13:05 patrickb left, patrickb joined
timo1 wow yeah the description from that other project i was comparing notes with was actually accurate in terms of the necessary fix, but not what the symptom is when you don't do that thing 17:37
18:24 lizmat_ left, lizmat joined 18:37 nativecallable6 left 18:38 nativecallable6 joined, harrow left 18:41 sourceable6 left, sourceable6 joined 18:44 linkable6 left, linkable6 joined 18:47 greppable6 left, greppable6 joined 18:50 notable6 left, notable6 joined 18:51 harrow joined 23:04 sena_kun left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!