github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nwc10 good *, #moarvm 06:32
nine good #moarvm, * 06:33
nwc10 children dispatched to schools(s) 06:34
I wonder how many super-spreader events we get this morning... :-(
nwc10 good *, brrt 08:40
brrt good * nwc10 08:46
jnthn morning o/ 09:05
nwc10 \o 09:19
lizmat nwc10: ugexe just posted on #raku-dev 12:59
m: say $*KERNEL.arch
camelia x86_64
lizmat could that be of help? Should probably live in the config as well, I guess :-)
nwc10 that shows up in the -V output. Seems that it can be more reliable than the value of $*VM.config.<osvers>. (But still doesn't distinguish between 32 and 64 bit ABIs) 13:03
Geth MoarVM/sparc: 0772199939 | (Nicholas Clark)++ | src/6model/reprs/P6opaque.c
Correctly align object references (ie pointers) in P6opaque object bodies.

Previously these were written at whatever offset the composer happened to be at, which meant that some were only 4-byte aligned. On systems with 8-byte pointers which care strictly about alignment, these leads to SIGBUS.
This is sufficient to get MoarVM, NQP and most Rakudo tests working on sparc64.		 14:20
nwc10 With that we build on "4.19.0"
"4.9.0" is what my Raspberry Pi reports. Sometimes $*VM.config.<osvers> is pretty much useless. 14:21
nine isn't that simply the kernel version? 14:22
nwc10 mmm yes, possibly it is. And I guess that Fedora name their kernels as advertisments: 3.10.0-957.27.2.el7.ppc64 14:23
nine My guess: that's kernel 3.10.0 with 957 distro patches, spec file version 27, build number 2, build target el7 and architecture ppc64 14:26
nwc10 957 distro patches -- you're paying for something....
nine Sounds realistic for security updates since the ancient version 3.10.0 14:27
Geth MoarVM: nwc10++ created pull request #1343:
sparc64 support		 14:42
nwc10 hey, github auto-suggested you. I have no idea why :-)
nine Maybe because I've looked at the sparc32 commit before 15:49
nwc10 it's stalking you
[Coke] Reminder: Voting for RSC is open. 16:14
nine nwc10: I guess at least some of your test failures are due to an outdated rakudo 17:12
nwc10: remember that make spectest will do a git pull in t/spec before running those tests
nwc10 yes but they only have the duration of the build, because usually I pull the lot just before I start 17:17
nine # Failed test 'sorting method list does not segfault'
There was a PR I merged over the weekend that changed our behavior here and we adapted the spec tests to it 17:18
The segfault in rakudo's build on P6opaque-debug boils down to: don't try to mix into a Scalar 17:27
nine Ok, this is definitely a bug: MVM_p6opaque_get_bigint_offset needs to bail if st->is_mixin_type 18:01
brrt good * 18:18
MasterDuke i'm getting errors because of `create_stub_boot_type(tc, MVM_REPR_ID_MVMSpeshCandidate, SpeshCandidate, 0, MVM_BOOL_MODE_NOT_TYPE_OBJECT);` and `meta_objectifier(tc, SpeshCandidate, "SpeshCandidate");`, but i just copied what had been done for MVMSpeshPluginState 19:26
'error: ‘MVMInstance’ has no member named ‘SpeshCandidate’'
nwc10 nine: shouldn't setting st->is_mixin_type = 1 in type_object_for in src/6model/reprs/P6opaque.c be enough to "force" the correct invariants that spesh and the JIT "know" about - that if body->replaced is non-NULL that flag also must be non-zero 19:27
meanwhile I am resting sparc64 and ppc64 with to-be-sure to-be-sure master
I think I am guilty of PEBKAC
MasterDuke if i comment out the create_stub_boot_type and meta_objectifier i added, instead i get `src/6model/reprs.c: In function ‘MVM_repr_initialize_registry’:src/6model/reprs.c:229:34: warning: implicit declaration of function ‘MVMSpeshCandidate_initialize’; did you mean ‘MVMSpeshPluginState_initialize’? [-Wimplicit-function-declaration] 229 19:40
| const MVMREPROps *repr = MVM##name##_initialize(tc); \ | ^~~src/6model/reprs.c:291:5: note: in expansion of macro ‘register_core_repr’ 291 | register_core_repr(SpeshCandidate);`
ugh, that looked pretty when pasted 19:41
but i do have an `MVMSpeshCandidate_initialize`
nine nwc10: well that in MVM_p6opaque_get_bigint_offset is definitely a bug. sp_bool_I would blindly take that offset and add it to the object pointer, not caring about a replaced body. The easy solution is to not spesh a bool_I to sp_bool_I on mixins 19:43
MasterDuke my current diff gist.github.com/MasterDuke17/55418...d7a6d1ddda ... 19:44
nwc10 oh yes. I see 19:45
return sizeof(MVMObject) + repr_data->attribute_offsets[slot];
dogbert17 setting this flag (github.com/MoarVM/MoarVM/blob/mast...rame.c#L7) to 1 and trying to build rakudo outputs a massive amount of messages like this: 20:07
Inconsistent spesh preselection of '!cursor_fail' (90): got 1, not 2
at <unknown>:1 (<ephemeral file>:)
from gen/moar/stage2/QRegex.nqp:2258 (/home/dogbert/repos/rakudo/install/share/nqp/lib/QRegex.moarvm:parse)
is it something to worry about? 20:08
jnthn MasterDuke: I don't see a change to instance.h; did you add a field there? 20:11
Or am I just missing that addition?
If not, that could be the issue
MasterDuke no. but i thought i looked and some other reprs didn't have a field 20:12
and i don't see why an instance would need a speshcandidate? 20:14
i may have just copied too much from the commit nine++ gave as inspiration github.com/MoarVM/MoarVM/commit/c61236f96e 20:15
Geth MoarVM/P6opaque-debug: 45c1341aae | (Stefan Seifert)++ | src/6model/reprs/P6opaque.c
Fix potential outdated reads and segfaults on mixed into bigints

For mixin types the P6opaque's body is replaced, so we must not just take an offset and add it to the objects base address (like sp_bool_I does). Better leave those ops unspeshed.
jnthn MasterDuke: It's to hold the type object, which you need in order to create an instance of it 20:18
MasterDuke ah ha! type objects
oh, jinx
i was looking at github.com/MoarVM/MoarVM/blob/mast...nce.h#L290 and didn't think i needed something like that, not at something like github.com/MoarVM/MoarVM/blob/mast...nce.h#L438 20:19
nice. i still get the `warning: implicit declaration of function ‘MVMSpeshCandidate_initialize’`, but moarvm builds now 20:23
nqp does not
well, the warning was just because i forgot to add it to the .h 20:27
hm, is this still allowed now that i've made it a repr? github.com/MoarVM/MoarVM/blob/mast...#L167-L179 20:32
jnthn Think it's OK; it looks like its a list of pointers to spesh candidates 20:45
And "all" that's changed is that the pointers are to GC-managed objects now 20:46
However, the second gen check/barrier below may become redundant
MasterDuke yeah, really wasn't sure about those. and i do create the new candidate that's added to the list via MVM_repr_alloc_init instead of calloc, so hopefully good there 20:48
the segfault in nqp is in the new gc_mark
jnthn Well, if you're getting to the new GC mark that's at least something :) 20:49
MasterDuke `MVM_gc_worklist_add(tc, worklist, &(candidate->inlines[i]));` how do i know that the `void *data` passed to gc_mark is the/a MVMSpeshCandidateBody instead of a/the MVMSpeshCandidate? 20:50
jnthn Well, not sure you can by inspection, but that's what the gc_mark always gets passed 20:51
That line looks dubious to me, though 20:52
MasterDuke oh?
jnthn I think that points to an MVMSpeshInline
Which includes some GC-able things to mark, but is not itself a GC-able thing
(And doesn't need to be)
MasterDuke ha. i adapted it from gist.github.com/MasterDuke17/55418...patch-L133 but it looks like i lost the trailing `.sf` 20:53
jnthn It should be...yes, exactly :-) 20:54
I was just finding that to point you at :)
MasterDuke new segv in unmanaged_size. how accurate does that have to be? 20:55
oh, guess there won't always be a jitcode, can't just blindly dereference its size 20:56
MasterDuke heh. `Try to enter NULL jitcode`, yeah that might cause a problem 21:02
brrt how did that happen 21:15
lizmat and another Rakudo Weekly News hits the Net: rakudoweekly.blog/2020/09/07/2020-...ime-again/
MasterDuke brrt: i think i've missed a few places where i need to change `spesh_candidate->jitcode` to `spesh_candidate->body.jitcode` 21:16
brrt ah 21:22
lizmat++
MasterDuke would this still be correct after my change? github.com/MoarVM/MoarVM/blob/mast...3560-L3567 22:28
Geth MoarVM: MasterDuke17++ created pull request #1344:
WIP convert MVMSpeshCandidate to a REPR		 22:50
MasterDuke ^^^ so people can easily see the current diff 23:00
off to sleep

Powered by Cro and the Raku® Programming Language.

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

Thank you!