Timo the timo1d ago

Dipped my toes in #AFLplusplus over the weekend was a kinda nice distraction / pastime.

Got #moarvm (language runtime for #rakulang) its first fuzzing target that exercises the streaming decoder system which is what you would use when reading strings (rather than bytes) with some encoding from a streaming source like the output of a process you're running.

Was a big help to actually put rules in the Makefile to generate the different variants (one with cmplog, one with asan, one with lcov, one with just afl instrumentation) of all the .o files, but I'm not so happy with the rules I came up with.

And to add to the pain, of course there's always nmake which I don't feel like figuring out what exactly I have to do to replace the usage of addsuffix I have ...

https://github.com/MoarVM/MoarVM/pull/1996

If you want to chime in with ideas for what would be good to do with fuzzing in this context, send a comment or toot!

Giving MoarVM its own instrumentation for moarvm bytecode for path coverage would be cool for the future!

Show threadTimo the timoJan 23

@tekknolagi #MoarVM, the virtual machine that runs #rakulang, has a dynamic specializer where functions get individual "candidates" based on the shape of the callsite (number of positional arguments, names of keyword arguments, native types of arguments (obj, str, double, or int)) and makes "certain" specializations with no extra assumptions or "observed" specializations with checks for actually passed types seen at run time.

default values are created per-call like ruby, not per-function-creation like python, so that part matches up.

since our list of candidates grows at run time, we don't generate one big compiled function at once like (I assume) you're doing.

this is essentially what your Approach 3 is doing, though we have equivalent instructions to the LoadArg you speculate in Approach 2.b, which we use in the interpreter as well as in situations where we can't specialize for the incoming arguments for whatever reason.

Happy to answer any specific questions or provide examples

Timo the timoJan 4

Emitting a little section with one jmp to the start of every BB from after the last real instruction with cheeky little mov rax, (index of BB) every 16 steps for readability doesn't penalize the generated code as much as putting a jmp to X, nop, mov rax, (index of BB); nop, X in between BBs, but both the regular view in perf report's annotate view and objdump's --visualize-jumps aren't very practical for the "all jmps in one place" approach ...

JITDUMP doesn't seem to allow me to have overlapping ranges, so I can't do something like have one range for the whole function and another symbol for each BB inside of it. If I do just that but don't have them overlap, then every BB will appear as its own whole function in the overview and not be disassembled together I think ...

I could spit out a fake source file that just has "BB 1" through "BB 100000" on each line and generate line number information records but uggghhhh I don't like that either :|

advice?

#pldev #assembly #x86_64 #rakulang #moarvm

Show threadElizabeth MattijsenSep 25, 2023

@Wrzlbrm

FWIW, I'm not that into config stuff and won't be of much help beyond what I suggested so far.

You might want to create a gist and post that on the #moarvm channel, or make an issue for in the MoarVM repo.

Show threadJonathan StoweDec 17, 2022

I've also fantasized about #MoarVM on an FPGA (one of those parts which pairs an FPGA with e.g. an ARM SoC would be awesome.)

But that's another thing that is never going to happen. (is MoarVM even expressable in a Hardware Description Language?)

twoot6Sep 17, 2019

▶ perl6org
▶ loltimo: Here's my latest progress report on moarperf, the browser UI frontend to the two profilers that #MoarVM (the VM that powers rakudo Raku / #Perl6):

https://wakelift.de/2019/09/12/progressing-with-progress/
▶ https://twitter.com/i/web/status/1173837577872400385

Progressing with progress.

Over the last months I have worked on the heap snapshot profiler, and now there's also things to see in moarperf's browser UI....

twoot6May 22, 2019

▶ perl6org
▶ loltimo: Wrote a blog post! #perl6 #moarvm

https://wakelift.de/2019/05/22/close-look-at-controlling-moarvm-profiler/
▶ https://twitter.com/i/web/status/1131265258520231936

A Close Look At Controlling The MoarVM Profiler

MoarVM is getting a new subsystem that allows users to programmatically configure specific parts of the runtime, such as what parts of the program the profiler should measure....

Lol, TimoNov 10, 2018

Here's actually a second blog post about my #perl6 #moarvm grant: a comparison of the deliverables/inchstones I had in the original proposal vs the current state. It's a little less exciting than my usual report style, but it does have screenshots :)

https://wakelift.de/2018/11/10/rakudo-perl-6-performance-analysis-tooling-progress-report/

Rakudo Perl 6 performance analysis tooling: Progress Report

In this post I compare the overall state of MoarPerf's implementation against the

Lol, TimoNov 9, 2018

I've posted the latest work report on the #perl foundation grant for the #perl6 #moarvm profiler frontend. Check it out! It has animated gifs!

watch out, though. one of them is like 16 megs big …

https://wakelift.de/2018/11/09/where-did-i-leave-my-at-key-s/

Where did I leave my AT-KEYs?

A week and a half after the previous work report on the MoarVM profiler frontend, here is another. This time it features changes to the overview page and a search feature for the call graph....

Lol, TimoOct 28, 2018

I just published my latest work report for my The Perl Foundation grant, the #perl6 #moarvm profiler frontend UI.

Read it here, and tell me what you think, if you want :)

https://wakelift.de/2018/10/28/full-screen-ahead/

Full Screen Ahead!

My report of improvements and additions to the perl6 profiler frontend UI since the last post....