github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
00:46
lucasb left
03:09
reportable6 left,
notable6 left,
benchable6 left,
bisectable6 left,
unicodable6 left,
nativecallable6 left,
shareable6 left,
squashable6 left,
coverable6 left,
undersightable6 left,
releasable6 left,
greppable6 left,
quotable6 left,
bloatable6 left,
statisfiable6 left,
evalable6 left,
committable6 left,
benchable6 joined
03:10
shareable6 joined,
committable6 joined,
bloatable6 joined,
nativecallable6 joined,
undersightable6 joined,
statisfiable6 joined
03:11
greppable6 joined,
notable6 joined,
unicodable6 joined
03:12
releasable6 joined,
coverable6 joined,
squashable6 joined,
quotable6 joined,
reportable6 joined
03:13
bisectable6 joined
03:14
evalable6 joined
05:50
robertle left
08:09
sena_kun joined
|
|||
lizmat | mornfall: you can use .tell to leave a message to pamplemousse | 10:57 | |
timotimo | maybe a comment on the blog post? | 10:59 | |
mornfall | lizmat: didn't think of that... i hoped their mentor might be around and relay the stuff if relevant | ||
timotimo | iirc brrt's the mentor in question? | ||
lizmat | mornfall: that could well happen, but .tell or leaving a comment in the post would ensure it doesn't fall through the cracks :-) | 11:00 | |
mornfall | .tell pamplemousse feel free to poke me if you are interested in ELF executables that run stuff that's not machine code without mucking with _start (and dealing with the unportability of that) | 11:04 | |
yoleaux | mornfall: I'll pass your message to pamplemousse. | ||
timotimo | i want an early version of confprog to land in rakudo for the upcoming release | 11:33 | |
12:04
AlexDaniel left
12:47
zakharyas joined
14:04
zakharyas left
14:38
AlexDaniel joined
16:42
lucasb joined
17:20
domidumont joined
18:37
domidumont left
18:46
ggoebel joined
18:51
ggoebel left
19:12
lucasb left
19:48
pamplemousse joined
19:50
brrt joined
|
|||
brrt | \o | 19:51 | |
pamplemousse | o/ | ||
yoleaux | 11:04Z <mornfall> pamplemousse: feel free to poke me if you are interested in ELF executables that run stuff that's not machine code without mucking with _start (and dealing with the unportability of that) | ||
brrt | .tell pamplemousse great post, very interesting | ||
yoleaux | brrt: I'll pass your message to pamplemousse. | ||
brrt | and ehm.... not sure I communicated this totally clearly, but I figured this would be a hard job, with no sure path to scucess | 19:52 | |
but everything you do learn is of course hugely helpful | |||
but if I understand it correctly, you can pack an MBC in an ELF, but MoarVM isn't quite a loader yet, correct? | 19:53 | ||
pamplemousse | brrt: Thanks! And yeah, I kind of figured it would take a bit of rooting around before figuring out the right approach. | 19:54 | |
yoleaux | 19:51Z <brrt> pamplemousse: great post, very interesting | ||
pamplemousse | Yep! I can make an ELF executable that is recognized as one and is potentially executable, but haven't figured out a way to get it to actually execute the MBC. | 19:55 | |
mornfall: Thank you so much for your feedback! If there's a way to write an ELF executable that runs something other than machine code without mucking around with _start, I would vastly prefer to do it that way | 19:57 | ||
brrt | pamplemousse: I know that guile scheme also has ELF as a binary format | 20:01 | |
mornfall | pamplemousse: hello | 20:02 | |
pamplemousse: you probably know that elf executables have sections and segments | 20:04 | ||
pamplemousse: it's not hard to take an executable and a data file and turn the data into a section of the elf file | 20:05 | ||
pamplemousse | mornfall: Okay, I'll take a look into that. | 20:06 | |
mornfall | pamplemousse: the easiest way to do that (for fast prototyping, at least) is objcopy: objcopy --remove-section .moarvm --add-section .moarvm=bytcode.bin --set-section-flags=[noload,]readonly elf_executable | 20:07 | |
now your choices depend on whether moarvm is available as a shared library or not | |||
if there's no moarvm .so, the dirty way to do it is this: write a C program that figures out its own location, find the offset/size of the .moarvm section, dump it into a file in /tmp and exec moarvm ... that's not the way you want to do it 'for real' but it'd probably work | 20:08 | ||
if there's an .so, you would make the section loadable (so it would show up as a segment in the executable that's loaded into memory), then just point moarvm at the location in memory that .moarvm got loaded at | 20:09 | ||
(i mean, in the latter case, you write a C program that just invokes dynamically linked moarvm as a library function) | 20:10 | ||
brrt | MoarVM is typically compiled to a .so | 20:11 | |
libmoar.so | |||
mornfall | good, that should make it fairly easy to make a nice production-ready 'packer' that links to moar dynamically | ||
(i know moar is not huge, but including it with every executable is still probably not what you want?) | 20:12 | ||
brrt | idk actually... there's arguments either way | ||
mornfall | well, it's really just a flip-of-a-switch thing with the above approach... you either link with -static or you don't (as long as you have both libmoar.so and libmoar.a) | 20:13 | |
brrt | but I guess for every application which you'd like to distribute as a binary, you could ship moar.so | 20:14 | |
pamplemousse | We could have both as options. I could see reasons why both of those would be useful | 20:15 | |
mornfall | should be easy to provide a switch for it to the user | 20:16 | |
nine | Do we even have a way to run precompiled scripts yet? | ||
brrt | not yet | 20:17 | |
well, you could for nqp probably | |||
mornfall | isn't that what `moar program.moarvm` does? | 20:18 | |
nine | I'd guess even nqp has some startup code that's still geared towards compiling something first | ||
brrt | MoarVM by itself, isn't | 20:19 | |
nine | mornfall: you usually do not start Perl 6 or even NQP programs with `moar whatever.pl6` :) There's a reason for using `perl6` or `nqp` | ||
mornfall | nine: sure, but .pl6 is not precompiled | 20:20 | |
brrt | nine: what's blocking perl6 precompilation, ooc? | ||
mornfall | pamplemousse: (from a quick look, you would want to replace MVM_cu_map_from_file in the standard moarvm main() sequence, invoked in MVM_vm_run_file() to get a MVMCompUnit from something that's already loaded in memory) | 20:23 | |
MVM_cu_from_bytes looks like the thing to use if you can figure out the address and size of your .moarvm elf section | 20:24 | ||
nine | brrt: perl6's startup initializes stuff that's gonna be needed by the script. This startup code is also written around the assumption that we are gonna compile something that we're later going to execute. One would need to extract the initialization part and compile that into the script itself to be able to run it. | 20:25 | |
It's nothing super complicated, it's just that noone has done it yet. Except that IIRC pmurias gave it a try. I'm not sure what the results were though. | 20:27 | ||
In any case, this is what I'd tackle first, just so I had some useful .mbc in the first place to put into an ELF file | |||
mornfall | (again, a quick and dirty path to results would be objcopy --change-setion-vma .moarvm=0xNNNN where NNNN is something that doesn't conflict with the rest of the file and that can be hardcoded into the loader; then write the size of the bytecode into a separate section on a separate address, or something along those lines) | 20:29 | |
(there's another even quicker and even dirtier way to do an elf loader: just dump the .moarvm file into a C string literal and run the compiler on it) | 20:31 | ||
nine | Nowadays a part of the needed initialization is even compiled into the perl6 binary: figuring out the library search and repository paths | 20:32 | |
brrt | right. So that doesn't sound impossible, but it does sound a bit hard | 20:33 | |
well | |||
mornfall | (eventually, i would try to converge on a solution where the loader doesn't use hardcoded addresses, but instead the packer uses an ld linkscript to tie a symbol to the start/end addresses of the .moarvm section) | ||
pamplemousse | I'll try the quick and dirty approach first I think (thank you mornfall for all your help), and then see if I can make it nicer once I have something that works. Once that's working, I'll look into extracting out the initialization parts of perl6's start up (thank you nine) | ||
I'm AFK for a bit but I'll be back soon | 20:34 | ||
nine | An important part of initialization is loading the SETTING. That's usually done by Perl6::Grammar | 20:36 | |
brrt | a start could be a perl6 'initializer' that'd load the setting without the grammar? | 20:37 | |
mornfall | i *think* this sprunge.us/wWQXQZ might be perl5 code to turn arbitrary data into C string literals *hides behind a rock* | ||
brrt | anybody have any idea how to get the PID of a process invoked with 'system' | 20:38 | |
21:06
sena_kun left
21:23
brrt left
21:25
brrt joined
|
|||
brrt | yay, (some) floating point support now works... | 22:00 | |
23:03
brrt left
|