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:02 reportable6 left 00:04 reportable6 joined 01:30 discord-raku-bot left 01:31 discord-raku-bot joined 02:31 linkable6 left, evalable6 left 02:32 linkable6 joined, evalable6 joined 04:11 unicodable6 left, greppable6 left, committable6 left, reportable6 left, sourceable6 left, squashable6 left, benchable6 left, linkable6 left, bloatable6 left, statisfiable6 left, evalable6 left, tellable6 left, shareable6 left, quotable6 left, coverable6 left, notable6 left, releasable6 left, nativecallable6 left, bisectable6 left, benchable6 joined, unicodable6 joined, coverable6 joined, quotable6 joined 04:12 committable6 joined, tellable6 joined, greppable6 joined 04:13 bisectable6 joined, statisfiable6 joined, reportable6 joined, squashable6 joined, shareable6 joined, sourceable6 joined, bloatable6 joined, linkable6 joined 04:14 evalable6 joined, nativecallable6 joined, notable6 joined, releasable6 joined 05:47 frost joined 06:02 reportable6 left 06:05 reportable6 joined 06:38 MasterDuke left 06:58 patrickb joined 07:15 frost left 07:16 frost joined
Nicholas good *, 3mo 07:19
aha 07:20
3mo doesn't tab-complete
#moarvm does
08:03 MasterDuke joined 08:06 MasterDuke left 08:58 linkable6 left, linkable6 joined 09:04 MasterDuke joined
jnthnwrthngtn moarning o/ 09:30
Nicholas \o 09:34
MasterDuke it's nice to be back at my desktop. builds moar+nqp+rakudo quite a bit faster than the laptop. on the negative side though, it's quite warm here 09:36
jnthnwrthngtn The office is a bit warmer than I'd like, but cooling 09:38
nine MasterDuke: and presumably that also means that your vacation's over
MasterDuke yep, that's also a negative 09:39
Geth MoarVM: MasterDuke17++ created pull request #1516:
Convert more realloc+memset(0) to recalloc		 09:56
MoarVM/new-disp: 6da7bc6a25 | (Stefan Seifert)++ | src/core/frame.c
Don't MVM_ROOT stack allocated frames

Since stack allocated frames do not have a proper MVMCollectable header, putting them on the temp stack would lead to more interesting effects than desired.		 10:06
nine jnthnwrthngtn: gotcha :D
jnthnwrthngtn ? :) 10:07
Oh! :)
But hm
I thought the temp roots had handling for that
Ohh, but I guess the memory can get reused if we end up doing lazy deopt or similar 10:09
That's sneaky
Nicholas "more interesting effects than desired" - that's code for something? :-) 10:11
ASAN would be pleased?
jnthnwrthngtn My guess is that 1) we MVMROOT the frame, which normally is not a problem even if it's stack allocated because we account for that, but 2) we're unwinding frames, but unwinding a frame can result in new allocations on top of the callstack due to lazy deopt, meaning that 3) if we do a GC run it is effectively doing a use-after-free except it's not really a free visible to ASAN etc. just that memory means 10:13
something else now.
So interesting is probably "thinks it's looking at a collectable but it's just junk" 10:14
Which won't go well at all
Nicholas Fun!
jnthnwrthngtn nine++
Each of these GC bugs makes me glad how much dispatch stuff we can now write in NQP rather than C. 10:24
10:31 dogbert17 joined 10:32 dogbert11 left
nine Yeah, matches what I've seen 10:36
jnthnwrthngtn Currently doing the last bits needed for us to be able to have just MVMCapture, not MVMCallCapture, and also to get rid of invokewithcapture 10:37
MasterDuke any objections to merging github.com/MoarVM/MoarVM/pull/1516 ? CI is clean and nqp+rakudo build and passed tests locally 10:40
Geth MoarVM/new-disp: 95cda47e31 | (Jonathan Worthington)++ | 4 files
Make capturenamedshash op work on MVMCapture
 10:45
MoarVM/new-disp: 4b4191e74b | (Jonathan Worthington)++ | src/6model/reprs/MVMCapture.c
Make clone work on an MVMCapture
MoarVM/new-disp: fc6d2c9edc | (Jonathan Worthington)++ | src/6model/reprs/MVMCapture.c
Fix copy-pasta
11:07 dogbert11 joined 11:08 dogbert17 left 11:13 dogbert17 joined 11:16 dogbert11 left
Geth MoarVM/new-disp: 4dc6bf48c1 | (Stefan Seifert)++ | src/disp/boot.c
Fix possible access to fromspace in boot_syscall

We use name for generating exception messages later on, so we need to protect the pointer from getting outdated by the GC.		 11:28
dogbert17 nine: let me know if you're running out of GC errors :) 11:35
jnthnwrthngtn
.oO( Or me, I can write more C code! )
 12:01
12:02 reportable6 left
Geth MoarVM/new-disp: aeef162d54 | (Stefan Seifert)++ | src/core/frame.c
Fix possible access to fromspace in MVM_frame_dispatch

This was clearly an oversight when rebasing the branch, missing the MVMROOT that got added to the original of the code on master. Pointed out by static analysis.		 12:03
12:05 reportable6 joined
Geth MoarVM/new-disp: ccdf42a1d6 | (Stefan Seifert)++ | 3 files
Fix possible access to fromspace in MVM_capture_from_args

In resume_init_capture arg_info is stack allocated and holds a pointer to a list of registers. This list may not be referenced anywhere else. When the MVMCapture is allocated, this could trigger the GC and object or string pointers in those registers could become outdated.
Fix by adding a place to the MVMThreadContext where we can reference the MVMArgs from and access it in the GC. This feels more like a workaround than a proper fix but it lets us progress and hopefully someone will come up with a prettier solution.		 12:07
nine This was the big one ^^^
Altai-man nine++ 12:17
jnthnwrthngtn I'm still a bit surprised about this, in so far as `.source = rec_resumption->initial_resume_args`, which comes from a recorded or run callstack record, which should be marking them there if needed 12:20
nine jnthnwrthngtn: but, rec_resumption->initial_resume_args = MVM_fixed_size_alloc(tc, tc->instance->fsa just a few lines earlier 12:22
jnthnwrthngtn Oh, we copy them there... 12:26
hm, why, since putting them in a capture will too...
ohhh, I see 12:27
An alternative appraoch would be, in the loop that sets it up, to see if the flag indiates it's a string or object and add them as a temp root, keeping a count of how many were added, and pop them later 12:28
Which is more localized
But not pretty
nine That was my first idea. But I didn't know how hot that code is and setting a single pointer will be faster 12:29
Geth MoarVM/new-disp: cc453ecaa5 | (Jonathan Worthington)++ | src/core/args.c
Make [use|save]capture use MVMCapture

This eliminates the last place that we create an MVMCallCapture.
MoarVM/new-disp: 8a7bb6c9c5 | (Jonathan Worthington)++ | 2 files
Don't create CallCapture type any more

This means that the REPR associated with it can go away soon.
MoarVM/new-disp: 34874166d4 | (Jonathan Worthington)++ | 11 files
Remove invokewithcapture op
nine Aaah...removed code is debugged code :) 12:30
Geth MoarVM/new-disp: 591b3a70f3 | (Jonathan Worthington)++ | 2 files
Remove JIT of various capture ops

It's out of date now, and all these calls are now just function calls, so can be reinstated more simply/directly in src/jit/graph.c.		 12:42
MoarVM/new-disp: a96a433bd3 | (Jonathan Worthington)++ | src/core/interp.c
Remove MVMCallCapture branches of ops

Since all of the functions on an MVMCapture already check that it is of the appropriate representation, don't repeat those checks in the interpreter. This will also simply re-adding JIT of these ops.
jnthnwrthngtn More debugging :D 12:43
Geth MoarVM/new-disp: 1e7c29ab89 | (Jonathan Worthington)++ | 8 files
Remove the MVMCallCapture REPR

And all of its associated functions.		 12:47
nine dogbert17: actually it looks like I have run out of issues to fix :D Made it through build, make test and make spectest with GC_DEBUG=2 + memory poisoning + a ton of extra fromspace checks I added 12:50
Of course, with your knack for finding issues, you probably try one test and come up with 3 new bugs :P 12:53
MasterDuke nine: any of the new info in github.com/rakudo/rakudo/issues/4462 suggest a fix? 12:55
dogbert17 nine: there's always the heap overflow from yesterday 12:56
Geth MoarVM: 8f513d559a | (Daniel Green)++ | 4 files
Convert more realloc+memset(0) to recalloc

I did this once back in 2017, but I guess a few new ones snuck in since then.
MoarVM: 04f8108173 | MasterDuke17++ (committed using GitHub Web editor) | 4 files
Merge pull request #1516 from MasterDuke17/convert_realloc_plus_memset_0_to_recalloc_part_2

Convert more realloc+memset(0) to recalloc
MasterDuke ^^^ silence was taken as consent 12:57
nine That's ^^^ what they told us at University ;)
ugexe i was just thinking that doesnt sound quite... right 12:58
dogbert17 nine: I used MVM_GC_DEBUG=1 and a 4k nursery to trigger the overflow. gist.github.com/dogbert17/3cc91104...2612b50a24 12:59
nine ugexe: I think the crucial difference is whether it's a group' or an individual's silence 13:00
jnthnwrthngtn nine: Does NativeCall somewhere do some code-gen and spit out call ops? 13:02
like prepargs and so forth?
nine No, that's done by call handler in QASTOperationsMAST with just a few minor adjustments for nativeinvoke 13:06
Of course...that may have changed drastically now?
jnthnwrthngtn ah, right, I see 13:07
Yeah
Well, it can stay for now
But it'd be good to later re-work it using new-disp
I suspect it can all be rather more efficient :D 13:08
nine Yeah, that's what I'm hoping :)
Are there any big changes with regards to native values? 13:09
jnthnwrthngtn: there's a bit of a thinko here: github.com/MoarVM/MoarVM/blob/new-...ite.c#L258 at this point the array has not yet been extended, because you changed the MVM_realloc to MVM_fixed_size_realloc_at_safepoint in github.com/MoarVM/MoarVM/commit/0a...c64b8b9662 13:16
That causes the heap buffer overflow 13:17
Does the fixed size allocator zero out the memory in realloc? In that case the memset could just go
MasterDuke nope github.com/MoarVM/MoarVM/blob/new-...#L222-L266 13:20
MVM_fixed_size_realloc_zeroed would probably be easy to create 13:21
jnthnwrthngtn nine: Huh, I thought it was the free of the previous location that was delayed, and the extension was immediate? 13:22
nine Oh, wait a minute. I think the misunderstanding is mine
What jnthnwrthngtn said :D
I got confused by the name
jnthnwrthngtn Hm, it's odd too because we're holding a mutex_callsite_interns lock at that point so I can't see how there'd be a race either 13:23
13:28 frost left
Nicholas nine: lunch [ ] coffe [ ] sleep [ ] ? 13:28
nine all of the above :D 13:29
Nicholas beer [ ] ? 13:30
I managed a dry day yesterday. Up to then I'd been slacking a bit
too much eating out, among other excuses
Geth MoarVM/new-disp: e0dc371c44 | (Jonathan Worthington)++ | 13 files
Start ripping out legacy bytecode invocation

In preparation for reinstating spesh for the new dispatch approach. Also get rid of legacy method lookup bits in the optimizer/JIT. We can't yet fully remove ops involving the legacy calling conventions because for now NativeCall is relying on them.		 13:38
jnthnwrthngtn I'm still ~10 days off convenient eating out
(For now, I need to do a self-test and write a sworn declaration that I did it and it was negative) 13:39
MasterDuke is there a reason the deprecated subs in lib/MAST/Ops.nqp need to keep their body? 13:43
Nicholas we 13:44
MasterDuke it was nice to be able to go out to eat like normal while i was on vacation. did quite a bit of it though, will have to make up for it now
Nicholas we're back to inconvenient eating out, as E has now passed the age threshold to need a test or vaccination, and the system wouldn't let you even book vaccinations until you are old enough 13:45
as if if would have a slot free on the same day.
nine Oh...could it be just a false positive? We're reallocing from 812 to 816 bytes. Both end up in bin 101. So the fixed size allocator just returns the same pointer as it knows that it already allocated enough space for the larger size. 13:51
Indeed, turning on FSA_SIZE_DEBUG makes the error go away 13:57
MasterDuke huh. but how is this the first time asan ran into that situation? 13:58
Geth MoarVM/new-disp: bfe32edeb3 | (Jonathan Worthington)++ | 4 files
Further cleanup of legacy invocation handling
 14:02
MoarVM/new-disp: 5001d695e6 | (Jonathan Worthington)++ | 4 files
Switch startup invocations to go through dispatch
 14:06
jnthnwrthngtn My goodness there's lots of little places to update... 14:10
Did anyone start working on removing findmeth/can?
nine Nah, still busy fixing memory issues
jnthnwrthngtn OK, I'll do it, 'cus killing off MVM_frame_invoke usages is pretty near the top of my todo list 14:11
And that contains multiple
MasterDuke i just got distracted by tools/update_ops.raku
nine jnthnwrthngtn: I think you broke rakudo's build 14:15
Getting a segfault in MVM_gc_write_barrier which is getting called with update_root=0x0 by p6captureouters 14:16
dogbert17 nine: are the 'Conditional jump or move depends on uninitialised value(s)' also false positives then? 14:21
Geth MoarVM: a27efd30a4 | (Stefan Seifert)++ | src/core/fixedsizealloc.c
Fix overflows on slight reallocations of fixed size alloced buffers

MVM_fixed_size_realloc and it's at_safepoint version take a short cut when the new size of the buffer falls into the same bin als the old size, as we always allocate the full bin size anyway. However they didn't check if the buffer was allocated from a bin in the first place. So we ended up just not doing slight reallocations of malloced buffers.		 14:24
nine dogbert17: turns out, it wasn't a false positive after all
No idea why this didn't show up earlier. It's a pretty clear bug on master 14:25
lizmat do we want that to be in 2021.07 ?
I could bump MoarVM for that, I guess
MasterDuke wow
nine I'm inclined to say yes
lizmat ok, will bump then
Geth MoarVM: MasterDuke17++ created pull request #1518:
Fix typo in filtering ops to gen		 14:26
lizmat MasterDuke: ^^^ would that need to be bumped as well ? or is that more of a support issue 14:28
MasterDuke it needs a bump and something else (maybe some kind of rebootstrap) to have any impact for nqp, but it's not necessary to do right away 14:31
dogbert17 nine++, you're on a roll. I might actually be out of bugs atm. 14:32
jnthnwrthngtn nine: Can't repro that; did you `make clean` first?
lizmat MasterDuke: ok
MasterDuke i see the names that i removed in src/vm/moar/stage0/MASTOps.moarvm, but i just did a rebuild and rebootstrap and they're still there (but not all the DEPRECATED_* names, so something removed the others previously)
jnthnwrthngtn Please don't rebootstrap NQP maser
*master
It will make the new-disp rebase/merge hell
Well, it may 14:33
Actually I guess I just take the new-disp ones
So it's not so bad
Well, maybe...
nine: I removed some things in the instance structure and it may just be that the extops weren't rebuilt 14:34
MasterDuke if that PR is merged and then you rebase new-disp and re-run update_ops.raku and rebootstrap, its changes will get picked up automatically
but i don't know why those names are still there after i do a local rebootstrap 14:35
Geth MoarVM/new-disp: 2cbbb3df0e | (Jonathan Worthington)++ | 17 files
Remove [try]findmeth and can ops

And quite a bit of code that they depended upon.		 14:37
Nicholas - /* Mutex taken when install specializations. */ 14:40
that sentance word missing, surely? But it's all gone now
nine jnthnwrthngtn: ah, yes, that was it 14:41
Can now confirm that with my fix from master, the heap overflow is also gone on new-disp
MasterDuke hm. should i remove the regen i did in my pr? would that make a rebase easier for new-disp? 14:42
nine MasterDuke: think so 14:43
jnthnwrthngtn grmbl, another rebootstrap didn't remove the istrue/isfalse, but where the hell do they come from
MasterDuke ok. but to satisfy my curiosity, how does one remove those names from src/vm/moar/stage0/MASTOps.moarvm? 14:44
lizmat MoarVM bumped 14:45
MasterDuke commit removed from pr
nine Looks like we're leaking MVMCallStackDispatchRecords' temps 14:49
Geth MoarVM/new-disp: 143b32076e | (Jonathan Worthington)++ | 11 files
Remove if_o/unless_o/istrue/isfalse ops
 15:05
MasterDuke didn't ^^^ already happen? 15:07
jnthnwrthngtn I did the work on it last night, but it turns out we still emitted an isfalse op in NQP; I just found out where, fixed it, and now could apply it. 15:08
$ git grep '\->invoke(' | wc -l 15:09
27
grmbl, all those need to go away
MasterDuke ah 15:11
m: class A { method a() is pure { say "hi" } }; say A.^methods 15:12
camelia (Method+{is-pure}.new BUILDALL)
MasterDuke vs
m: class A { method a() is default { say "hi" } }; say A.^methods
camelia (a BUILDALL)
MasterDuke some traits cause the gist to not use .name and instead fall back to the type name+role name 15:13
why/how the difference?
nine MasterDuke: I guess that's because the role for default is anonymous while the one for pure is called is-pure 15:14
MasterDuke m: class A { method a() is DEPRECATED { say "hi" } }; say A.^methods 15:15
camelia (a BUILDALL)
MasterDuke don't think so, DEPRECATED is a named role also
oh, but DEPRECATED is added via `does` instead of `.^mixin` 15:18
maybe that makes a difference
15:20 linkable6 left, evalable6 left 15:21 linkable6 joined 15:23 evalable6 joined 15:26 patrickb left
Geth MoarVM/new-disp: 7fc782db31 | (Jonathan Worthington)++ | src/core/frame.c
Remove spesh handling from legacy invoke

In preparation for adding it to the dispatch-based invocation.		 15:33
MoarVM/new-disp: 681cba7ee9 | (Jonathan Worthington)++ | 4 files
Update spesh arg guard evaluation for new convs

Since we didn't do enough updates to be producing spesh candidates yet, this will consistently find nothing.
MoarVM: af001c9675 | (Stefan Seifert)++ | 2 files
Fix possible deadlock when waiting for mutex_threads

Usually when we wait for getting a lock on a mutex, we mark the waitingthread as blocked so another thread may steal our GC work. This isn't a good idea for the instance's mutex_threads though as the GC also acquires a lock on that mutex and we can end up in a dead lock. Since all places that use this lock only hold it briefly, marking the thread as blocked isn't really that ... (6 more lines)		 15:39
MoarVM: 3a3eb7f9da | (Stefan Seifert)++ | 2 files
Fix 2 spelloes. MasterDuke++
 15:43
MoarVM/new-disp: 7ff0b83a72 | (Jonathan Worthington)++ | src/spesh/dump.c
Update spesh callsite dumper for new convs
 15:52
MoarVM/new-disp: ccca48ed56 | (Jonathan Worthington)++ | 3 files
Update spesh frame entry logging for new convs

But don't switch it on yet, otherwise we'll quickly crash and burn due to lots of other spesh updates that are needed.
MoarVM/new-disp: 2579c66c03 | (Jonathan Worthington)++ | src/spesh/args.c
Adapt named args optimization to new convs
 16:05
MoarVM/new-disp: 0149e0ec40 | (Jonathan Worthington)++ | src/spesh/dump.c
Eliminate one more arg_count usage
timo jnthnwrthngtn: could you benefit from me cherrypicking the spesh correlation id setting commit from my branch onto new-disp? 16:13
MasterDuke huh. `Serialization error: parameterized type to intern not in current SC` if i add `$r.^compose;` here github.com/rakudo/rakudo/blob/mast...s.pm6#L428 16:32
jnthnwrthngtn timo: I already have it doing that in new-disp now, I think 16:34
timo ah, ok!
jnthnwrthngtn Current problem is that JIT explodes
And the JIT of sp_getarg_* certainly needed updating but...
...my attempt to do so didn't help. I'm not sure if that is the thing with the wrong JIT, however 16:35
timo "the wrong jit" isn't template vs exprjit, right? it's about "did i jit it right"?
Geth MoarVM/new-disp: e790ea6680 | (Jonathan Worthington)++ | src/core/interp.c
Only frames using new convs can be specialized

So simplify the sp_getarg ops in the interpreter.		 16:36
MoarVM/new-disp: b52a09035b | (Jonathan Worthington)++ | src/jit/x64/emit.dasc
Attempt to update sp_getarg_* in the lego JIT

The JIT is still, alas, rather explosive.
MasterDuke oh, now it's fine. maybe a problem with an outdated nqp
jnthnwrthngtn timo: Well, I'm using MVM_JIT_EXPR_DISABLE=1 for now 'cus I know I didn't update the expression JIT
But I still get explosions. You can uncomment the two calls to MVM_spesh_log_entry in order to enable spesh and observe it 16:37
timo: The latest commit is my attempt to fix it; maybe you can spot some thinko in there
timo do yo uneed to grab the address of the map rather than the value perhaps 16:38
like does mov TMP1, FRAME:TMP1->params.arg_info.map; have to be lea instead of mov 16:39
jnthnwrthngtn .map is a poitner to an array
timo ah
jnthnwrthngtn Well, a MVMuint16*
So that should already be reading the pointer
I wonder if I got the widths wrong somewhere
timo i have no experience with the U16:TMP[idx] syntax you're using here
jnthnwrthngtn Me either. :P 16:40
brr<tab>...aww
Of course, this may not be the reason for the SEGV
timo a few lines above has | mov TMP1, REGISTER:TMP1[idx]; and that works correctly
right, it could be that this unlocks the entirety of the jit to run and gives us a huge area of attack
MasterDuke huh. so adding `$r.^compose` to pure works (i.e., `class A { method a() is pure { say "hi" } }; say A.^methods` outputs '(a BUILDALL)'), but adding to nodal is what gives that `Serialization error: parameterized type to intern not in current SC` 16:42
timo you can disassemble when stopped in gdb, but i think you can only actually get earlier instructions if you get it to see the beginning address of the "function" 16:43
MasterDuke in stage mast of CORE.e.setting
timo like `x/i address` would "examine as instructions"
jnthnwrthngtn It segfaults on 16:47
mov (%rcx,%rdx,2),%rcx
Which looks rather like what I was doing
timo you know 16:53
jnthnwrthngtn ah, I shoudla sign-extended the uint16
timo why not put a `| mov TMP1, 0xFACEFACEFACEFACE` where you expect you are
jnthnwrthngtn Now rdx looks sensible
timo but yes indeed sign extending good idea
jnthnwrthngtn But rcx looks like a very dodgy pointer
Nicholas "who sold you that?" 16:54
Geth MoarVM/new-disp: 1564e5f3dc | (Jonathan Worthington)++ | src/jit/x64/emit.dasc
Fix thinko and add sign extension to sp_getarg JIT
 16:58
jnthnwrthngtn Nicholas: Me, I did a silly thinko and used a register for two things
timo how much should i be expecting to work fine with jit? 16:59
Nicholas jnthnwrthngtn: what, you mean x86_64 doesn' 17:02
doesn't do junctions at the hardware level?
jnthnwrthngtn timo: Given that sp_getarg only just stopped exploding, not much 17:05
timo i just ran a random nqp test with spesh log and it's just "received log with 0 frames having their statistics updated" over and over :D 17:07
makes me wonder if we ever want to log like the histogram of what spesh log entry types we see, since we iterate over them anyway to update the stats
jnthnwrthngtn You did uncomment the thing I mentioned, right?
timo oh!
i missed that
i see it now 17:08
yeah now i get a segfault, so i can at least look at what's happening :) 17:09
MasterDuke huh. changing the `$r.^mixin` to `$r does` gives `Cannot invoke this object (REPR: Null; VMNull)` during stage parse 17:10
timo => 0x470b20: add $0x0,%al
oh i have to set it to intel mode first 17:11
jnthnwrthngtn timo: Note that I iddn't fix up the EXPR JIT at all for sp_getarg* yet 17:12
timo yes i disabled that (i hope)
jnthnwrthngtn timo: So if you're not disabling that I suspect you'll run right into the same issue
The thing I see is a segv in the interpreter, in fact
(with the NQP test I picked)
MVM_JIT_EXPR_DISABLE=1 ./nqp-m t/nqp/003-if-else.t 17:13
dogbert17 hmm, is the build currently broken?
timo i got the env var name reversed 17:14
dogbert17 I get: 17:15
Building NQP ...
/usr/bin/perl Configure.pl --prefix=/home/dogbert/repos/rakudo/install --make-install --git-protocol=https --no-relocatable --no-ignore-errors --silent-build --no-force-rebuild --backends=moar --gen-moar
istrue/isfalse were superseded by the general dispatch mechanism
This compiler is based on HLL::Compiler.
timo i see a segfault in existskey where it kind of looks like the STable of the object doesn't look very healthy 17:16
jnthnwrthngtn timo: Yes, that's the one I see
timo i'll build it on my desktop so i have rr 17:17
jnthnwrthngtn dogbert17: Sounds like you need to pull latest NQP
dogbert17 the nqp new-disp branch?
jnthnwrthngtn Yes 17:18
b68cbcd7
Is the one that updated it for that 17:19
Time for me to go home
timo what, you're drunk? ;) 17:21
like in "go home you're drunk"
Nicholas Possible 100% otherwise. Based on previous public information, he was in the office today. And I've never heard mention of an office beer fridge.
(Coffee exists at both locations) 17:22
(I believe that the office doesn't *need* a beer fridge as it has a fully operational pub "on tap")
I wonder *why* they chose that location for an office...
timo huh. follow-fork-mode child and follow-exec-mode new don't get me into the actual nqp code?! 17:26
aha. `rr replay -p moar` waits for a process with name "moar" gets exec'd 17:33
not getting it right just yet 17:35
okay i'm sure this isn't the right way to do it, but i haven't found another just yet: rr replay -t <start at like 100 and go up while you get output, then back down slowly until you get output again> and then rr replay -g that-number 17:41
00030 dispatch_o loc_8_obj, 'lang-meth-call', Callsite_4, loc_7_obj, loc_12_str, loc_8_obj, loc_1_obj 17:42
[later]
00034 -> existskey loc_9_int, loc_11_obj, loc_12_str
17:43 evalable6 left, linkable6 left
timo sorry, wrong 17:50
no, correct actually; i was just stepping through the wrong dispatcher program :D 17:51
this one was stringifying what loc_12_str gets
ok i *think* i'm correctly stepping into the jitted version of "method_table", which is what the "lang-meth-call" calls 18:01
18:02 reportable6 left
timo i'm trying to view the contents of the hash that it would be accessing here, but MVM_str_hash_fsck segfaults :\ 18:15
jnthnwrthngtn Sounds pretty fscked to me...
Nicholas is right - no beer fridge at office. The office is located where it is because I used to live in the same building, and knew the landlord was good, and was looking for an office, and just in time one became free. :) 18:16
Of course, that makes the question "did you deliberately choose to live near a pub", and I guess there answer is "have you seen the pub density in Prauge?" :P 18:17
timo so did you choose prague because the pub density makes the question whether you decided to live / work near a pub useless? :) 18:20
jnthnwrthngtn Maaaaybe :P
timo: I'm assuming that the loc_8_obj ends up in loc_11_obj by the time of the existskey? Or something connects these two? 18:21
timo there's a set in between, yeah
jnthnwrthngtn Dinner is ready, bbl 18:22
timo i think the "when" isn't very precise, so i'll have to step around a bit more backwards and forwards, but i don't really have a reason to believe what goes in or what happens inside method_table is going wrong
ok but why do we stringify that result tho 18:26
Altai-man "no beer fridge at office" he says, but evidences... 19:11
19:22 psydroid joined 19:28 dogbert17 left
timo 0x7f3cfaee4062: test rdx,rdx 19:30
0x7f3cfaee4065: jne 0x7f3cfaee4072
what's that all about?
19:31 dogbert17 joined
nine depends on the context? 19:33
It's a bit of a weird spelling, but it simply jumps if rdx is != 0 19:36
20:05 evalable6 joined
timo ok, i was thinking that's probably a null check 20:06
mov QWORD PTR [rbx+0x20],rdx - this is access to the 0x20 / 8th register, right? 20:07
nine if rbx is the base address of the work array rbx+0x20 should be the 4th register (8 bytes per pointer) 20:12
timo it was that, yeah 20:20
20:21 squashable6 left
timo here's what i think i have: 20:35
00000 sp_getarg_o loc_2_obj, 0
00001 sp_get_o loc_4_obj, loc_2_obj, 48
00002 return_o loc_4_obj
it kind of sort of feels like it's grabbing a BOOTStr out of that obj there
this should be getting the methods hash out of an NQPClassHOW 20:36
hum, and the param that comes in at source[map[0]] is an NQPClassHow 20:39
ok, let's see then if the getarg is compiled right 20:40
what do we emit a jmp rdx for? i don't see anything that actually sets rdx to anything 20:43
wha. rdx just has the address of the instruction that comes right after the jmp in it, right from the start of execution 20:45
oh! 20:47
the current frame has a params.version of 0
is that actually wrong? the legacy struct for the params doesn't look right either, but the map of that params is a null pointer? 20:49
i get the feeling we're dereferencing one too many times? 21:02
i think TMP1 + TMP2 * 2 is wrong? 21:12
21:13 dogbert17 left
timo well, changing it to TMP2 * 8 makes t/nqp/003-if-else.t work fine 21:13
this was for getting param_info.sources[param_info.map[arg_index]], it used to multiply the result from the map by just 2, but should have been 8 21:15
every time i run "make test" in nqp it does a bit of compiling first, which segfaults 21:26
why :|
MasterDuke yeah, that annoyed me a while ago and i did a little digging. it wasn't quite as easy to fix as i hoped 21:27
also you can't `make t/individual/test/file`, which maybe was related? 21:28
timo mhm, i just copypasted the "prove" line now
still a bunch of test files crashing, but many pass now 21:29
21:35 squashable6 joined
timo here's a crash that might be related to how named arguments work in the new argument format? 21:36
it's accessing the argument in map's slot number 3, but there are only 3 flags, one of which is named
so there are 3 valid entries in the map, 0, 1, and 2. 3 is what it's using instead and that's a much too high value, in the hundreds 21:37
Spesh of 'compile_node' (cuid: 119, file: gen/moar/stage2/QAST.nqp:6216) 21:38
Callsite 0x10636c0 (3 args, 2 pos)
- want
Spesh of 'compile_node' (cuid: 119, file: gen/moar/stage2/QAST.nqp:6216) 21:39
Callsite 0x10636c0 (3 args, 2 pos)
- want
Positional flags: obj, obj
Latest guard tree for 'compile_node' (cuid: 119, file: gen/moar/stage2/QAST.nqp:6216)
0: CALLSITE 0x10636c0 | Y: 1, N: 0
1: LOAD ARG 0 | Y: 2 2: STABLE CONC MASTCompilerInstance | Y: 3, N: 0
3: LOAD ARG 1 | Y: 4
4: STABLE CONC QAST::Stmts | Y: 5, N: 0
5: LOAD ARG 3 | Y: 6
6: STABLE CONC BOOTInt | Y: 7, N: 0
7: RESULT 0
fantastic how it has so many spaces at the end there
anyway, you can see how it's got a LOAD ARG 3 in slot 5, that's the one that asplodes
that's certainly a lot fewer failing tests 21:43
which is 0 21:47
the amount of failing tests in the nqp test suite is 09
no not 09, it's 0 21:48
Geth MoarVM/new-disp: 9f0e3c20a3 | (Timo Paulssen)++ | src/jit/x64/emit.dasc
Fix indexing into sources params array from map in the lego jit
 21:50
MoarVM/new-disp: c1cfd397aa | (Timo Paulssen)++ | src/spesh/arg_guard.c
the new params format doesn't have gaps for nameds. fix arg guards accordingly
23:22 dogbert17 joined 23:40 japhb left 23:44 japhb joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!