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
|