| leedo | perhaps related to FROGGS's last commit? gist.github.com/leedo/8c390fcbe47d5e2e5fd5 | 02:23 | |
| (rebuilding to make sure i'm not crazy) | 02:24 | ||
| ok, nuking my install dir seems to have fixed it | 02:30 | ||
|
04:56
cognominal joined
04:59
cognominal joined
05:06
cognominal joined
06:02
cognominal joined
06:04
cognominal joined
07:20
FROGGS joined
08:27
zakharyas joined
08:57
brrt joined
09:08
flaviusb joined
09:11
leont joined
10:58
zakharyas joined
11:07
jnthn joined
11:24
leont joined
12:24
rurban_ joined
|
|||
| dalek | arVM: a677430 | FROGGS++ | src/6model/reprs/P6int.c: include stdbool.h conditionally |
12:37 | |
| arVM/line_based_coverage: d33795d | timotimo++ | src/ (2 files): dead-end for trying to get more lines covered |
13:18 | ||
| arVM/line_based_coverage: 27aa4c5 | timotimo++ | tools/parse_coverage_report.p6: add a simple coverage report to HTML tool |
|||
| arVM/line_based_coverage_2: fb7373e | timotimo++ | / (11 files): first prototype of a per-line coverage reporter |
13:19 | ||
| arVM/line_based_coverage_2: 5608af6 | timotimo++ | / (6 files): add missing files, adjust op to not use spesh slot show MVM_COVERAGE_LOG in moar --help |
|||
| timotimo | (just a rebase to get rid of the "modified oplist from a branch and on master" problem) | 13:20 | |
|
13:20
dalek joined
|
|||
| timotimo | and now i'll teach that exporting tool about moar --dump | grep annotation: | 13:21 | |
| which will remove a whole bunch of red lines that we can't ever turn green | 13:22 | ||
|
14:00
pyrimidine joined
15:02
zakharyas joined
|
|||
| timotimo | hey jnthn; it currently looks like each little piece of code in QASTOperationsMAST would have to do its own line number annotation handling (and they don't do it); maybe that wants to live in compile_op itself? | 15:21 | |
| that's only really interesting for the core setting, but on the other hand, the core setting is the one place that we really want to have line-by-line coverage with | 15:22 | ||
| jnthn: i think i need a bit of guidance for this; i don't want to give every single mapper an extra argument for the $op.node, but add_core_moarop_mapping already discards everything but $op.op and $op.list | 15:38 | ||
| should i grab the return value of calling $moarop_mapper and putting that into an Annotated? | 15:39 | ||
| jnthn | Well, the idea was that we only really annotated stmts nodes | ||
| or stmt | 15:40 | ||
| timotimo | oh, hm. | ||
| i see the code in compile_all_the_stmts that puts the annotation in | |||
| jnthn | Meaning multi-line statements would end up with an annotation of their start line | ||
|
15:40
virtualsue joined
|
|||
| jnthn | The actual annotations you see in the bytecode, for the purposes of what you're doing, perhaps want to be interpreted as "this line and the next ones that aren't annotated" | 15:40 | |
| timotimo | could it be we're turning too many things into a sinlge stmt or stmts in the optimization phase? | ||
| that makes things ... uncomfortable :) | 15:42 | ||
| because in order to find lines to grey out i'm just grepping "annotated: " from the moar --dump | |||
| so now i'll have to differentiate between "this line doesn't show up, but it's between two annotations" and "this line never shows up anywhere" | 15:43 | ||
| alternatively ... i'm only looking for grey lines if a line doesn't show up with a "HIT" output from the coverage output | |||
| so if i make sure enough HIT lines show up for a single annotation ... that could work | 15:44 | ||
| do you think it'll be important to walk all annotations inside a BB or would it be enough to get the file/line number from the beginning of each BB? | |||
| i'll have to be extra careful about things like "is the inline bit set" and also only if the line of the latter BB is higher and has the same filename and ... | 15:48 | ||
| ugh | |||
| jnthn | Well, if we're in a BB we should probably run it to completion | ||
| timotimo | that's right | ||
| that part is clear; much more difficult is what exactly goes on between BBs | 15:49 | ||
| hoelzro | good moarning #moarvm! | 15:59 | |
| timotimo | so perhaps the line number annotation op gets another parameter for "how many lines does this correspond to" | 16:00 | |
| and i'll probably want to store up 4k or something of bytes before locking, writing, unlocking | 16:01 | ||
| jnthn | timotimo: That could be one way to do it, yeah | 16:07 | |
| timotimo | jnthn: so, going through all annotations that exist for a given BB, yea or nay? | ||
| jnthn | I think you'd have to go through the BB | 16:08 | |
| Multiple statemetns can be in one BB | |||
| timotimo | that's what i thought. OK! | 16:13 | |
| luckily, the IP of the beginning of the linear_next BB has to be correct (if it's not inlined) | |||
|
16:24
vytas joined
17:10
rurban_ joined
|
|||
| arVM/line_based_coverage_2: 3f0c647 | timotimo++ | tools/parse_coverage_report.p6: grey out lines that don't have annotations in the bytecode |
|||
| timotimo | jnthn: in order to have something like a bytecode annotation iterator, should i add a "next bytecode address" or "next annotation's address" field to MVMBytecodeAnnotation on top of the filename and line number fields? | 18:21 | |
|
18:31
zakharyas joined
18:33
leont joined
19:12
FROGGS joined
19:24
Peter_R joined
19:27
vendethiel joined
19:45
geekosaur joined
|
|||
| timotimo | instead of dealing with file locking, i'll spread out file output into pid-numbered files and keep the "append" logic, as only a single process (in the same process namespace) can have a given pid at the same time | 19:52 | |
| diakopter | timotimo: see line number spectest breakage in #perl6 | ||
| timotimo: I thought you hadn't merged it yet | |||
| oh now I see your messages there | |||
| *bloop* | |||
| timotimo | going to log -971268454 lines | 20:09 | |
| perfect! | |||
|
21:17
bartolin_ joined
21:18
patrickz joined
|
|||
| bartolin_ | I just dropped in to mention that MoarVM doesn't build on BSD currently: github.com/MoarVM/MoarVM/issues/311 | 21:19 | |
| bartolin_ does not know C, so the suggested patch might be plainly wrong ... | 21:21 | ||
| but at least I was able to build with that patch | |||
| diakopter | bartolin_: thanks for the contribution | 21:23 | |
| it might break osx? | |||
| don't know | |||
| geekosaur would suggest renaming the moar "fileno" instead, because there is no guarantee that fileno is also provided as a function | 21:24 | ||
| (well, there is on fbsd, there is not in general. and traditional (non-gnu) stdio has fileno defined as a macro) | |||
| I don't see a fileno function in libSystem.dylib on OS X | 21:26 | ||
| [Coke] | TimToady: build now warns at "src/core/CompUnit/RepositoryRegistry.pm" line 204 of 308 | 21:27 | |
| the $compunit there generates a useless... | |||
| bartolin_ | geekosaur: ahh, that's interesting (traditional stdio having fileno defined as a macro). I googled for a while but wasn't able to get a clear picture | 21:29 | |
| geekosaur | you basically saw it in clang's error message :) | ||
| bartolin_ | geekosaur: yes, but that was only my specific version of FreeBSD :-) | 21:30 | |
| geekosaur | fileno() macro gets turned into a field access through the (FILE *) | ||
| jnthn hasn't really expected a macro to apply on the RHS of -> | 21:40 | ||
| Or did I misread the error? | 21:41 | ||
| No, I didn't. It really does try to macro that. | |||
| [Coke] | jnthn: hey, can someone write an EBCIDIC to NFG converter? (not you, just wondering if someone who is excited about such a thing could) | 21:42 | |
| whoops, wrong window on the compunit thing. | |||
| geekosaur | CPP macros are dumb | ||
| jnthn | No kidding :) | ||
| geekosaur | they do not know C | ||
| jnthn | But yeah, a rename should deal with it | 21:43 | |
| timotimo | is getpid() crossplatform? | 21:46 | |
| jnthn | Doubt it | 21:49 | |
| May have to be _getpid() for MSVC | |||
| timotimo | the libuv docs use getpid() in a nexample, but i still thought i'd ask | 21:51 | |
| ah, indeed, we have a getpid function in moar already | 21:52 | ||
| this code is .. roundabout %) | 21:56 | ||
| but it makes extra sure that the format string it gets from the environment is sane | |||
| so i think that's worth something | |||
| actually ... | 21:58 | ||
| why don't i write a function that takes a string pointer from the environment to give back a file descriptor ... and if there's a %d in there it sanitizes the input as a format string, substitutes the %d for the pid and uses that | |||
| that way we'd be able to have .pid.txt files for jit log, cross thread log, spesh log, ... | |||
| and the coverage log, too | 21:59 | ||
| patrickz | Hey. I just installed moar (and nqp/rakudo/panda/some modules) with the executable stack bit turned off (linker option -z noexecstack). Stuff seems to work. Now I wonder, am I bound for failure? (Because there should be some reason for gcc to set that bit in the first place...) | 22:04 | |
| gcc on linux that is | |||
| timotimo | i don't think we try to execute anything on the stack. we only ever jump into the heap when we do JIT | ||
| noexecstack is a security feature, right? | |||
| it'd be swell if you could run "make spectest" (usually you want to set TEST_JOBS to number-of-processors + 1 or so) and see if it explodes due to trying to execute stuff on the stack | 22:05 | ||
| i suspect it won't. in that case it'd be cool if we had detection for how to set "noexecstack" on different OS/compiler combinations :) | |||
| patrickz | it's a mark on exec files that signals the program might use the feature. | ||
| SELinux prevents execution of moar on that machine of my hoster thus the fiddling with this stuff... | 22:06 | ||
| geekosaur | patrickz, as far as I know things default to exec-stack for historical reasons | 22:08 | |
| you can turn that off on the file and see if it works or segfaults | 22:09 | ||
| (since most things should not actually require it at this point) | |||
| patrickz | geekosaur: linux.die.net/man/8/execstack says the opposite | ||
| i.e. default to not turn that on except when finding gcc trampolines | |||
| geekosaur | interesting | 22:11 | |
| patrickz | hm, it says "recent GCC versions" that might be the key... | 22:12 | |
| geekosaur | although I note it also sets it based on libraries | ||
| so if the libs on the build system had execstack enabled, the executable would be so flagged | 22:13 | ||
| but if the libs on the run system don't have execstack then the program doesn't actually need it | |||
| timotimo | that's interesting. so whether or not stuff on the stack can be executed depends on what the IP is currently going through? | 22:17 | |
| geekosaur | ?\ | ||
| no, I am assuming a binary was copied between systems | |||
| patrickz | hm. I currently run the spec suite on a system that prohibits execution of libraries with that bit set. Looking good so far. | ||
| nope | |||
| I also built on that system | 22:18 | ||
| geekosaur | interesting | ||
| ok, that doesn't make much sense then; probably have to dig into docs for specific library and toolchain versions for that system (or if you are lucky, for the OS release it's running --- note that you may need hosting provider specific docs) | 22:19 | ||
| patrickz | it would make sense if that is an old gcc that defaults to "true" as you suspected or if there actually is some stack exec going on (which should make my spec run fail) | ||
| geekosaur | also stack exec may only happen in unusual circumstances | ||
| like "is native" functions with certain specific types, or something like that | 22:20 | ||
| (in perl6 terms) | |||
| basically it may allow for it but it's only a problem if it actually gets used, and perhaps nothing actually uses it yet | |||
| patrickz | gcc 3.3 introduced automatic exec stack detection | 22:29 | |
| 25 spec test failures. | 22:34 | ||
| I guess those are not related | 22:35 | ||
| timotimo | the spec test is currently quite unhappy, yeah :( | ||
| jnthn | Try make test also, which includes the NativeCall tests | 22:40 | |
| timotimo | ugh. ugh. ugh. | 22:47 | |
| some of these line annotations i come up with make 0 sense | |||
| patrickz | use-trace.t one failure callbacks.t no tests ran | ||
| jnthn | That callbacks.t one is suspect | 22:50 | |
| patrickz | is nativecall using nested functions? | 22:51 | |
| timotimo | but ... why would dyncall build its callback handlers on the stack? | ||
| jnthn | nested? | ||
| timotimo | no, wait ... | ||
| in order to actually call stuff, does it jump into generated machine code? | 22:52 | ||
| jnthn | patrickz: We delegate that stuff to dyncall or libffi | ||
| timotimo: Almost certainly for callbacks | |||
| patrickz | if I understand correctly that exec stack stuff is basically only needed for callbacks to nested functions. GCC uses some exec stack stuff for those. | 22:53 | |
| timotimo | jnthn: did you get around to fixing the problem with strings starting with an invalid utf8 character in utf8-c8? i don't remember ... | ||
| jnthn | timotimo: no | ||
| timotimo | OK, so my memory isn't bad on that | 22:54 | |
| jnthn | 'night, #moarvm | 22:56 | |
| timotimo | gnite jnthn | ||
| patrickz | good night | 22:57 | |
|
23:15
virtualsue joined
|
|||
| timotimo | HIT gen/moar/m-CORE.sHIT src/vm/moar/ModuleLoader.nqp 1 | 23:17 | |
| i don't actually know how i b0rk this. | 23:18 | ||
| ah, it's probably due to when some program crashes it doesn't flush that file descriptor | 23:19 | ||
| flush after every print? why, that's such a great idea! >_> | |||
| and, i'm sure, not slow at all | |||
|
23:51
konobi joined
|
|||