freenode/#sbcl - IRC Chatlog
Search
10:51:05
pfdietz
I've wanted to be able to compile sbcl with coverage, so I could see what parts are not being tested. Also, random test generation + coverage => automatically generating minimized tests that extend coverage.
12:00:48
pkhuong
pfdietz: the easiest way to get coverage everywhere might be editcore + HW/binary tracing like honggfuzz?
12:02:14
pfdietz
I want something where the coverage is made available in a form the reducer can easily access. It would also help if the a snapshot of the coverage could be taken and the state rolled back to the snapshot.
12:03:08
pfdietz
So: generate a test case, determine that it extends coverage, then reduce it to a minimal form that still extends coverage (and repeat that if the original had more coverage than the reduced form).
12:03:52
pfdietz
This is inspired right now by Doug K's comment on vop coverage in the most recent commit.
12:08:28
pkhuong
i don't have access to any machine with intel pt, but I do have BTS. i'll try to hack something up with intel's PMU today
12:28:00
pkhuong
the hardest part will be dropping branches to / from the C runtime and newly generated code
12:31:42
pfdietz
The approach I've taken on this sort of thing is instrumenting lisp when it's compiled. So if I can recompile part of the compiler, I can collect the information I want.
13:46:12
pfdietz
Ugh, obviously I was wrong. (let ((*macroexpand-hook* …)) <form>) does not affect the macroexpansions in <form>.
14:30:21
stassats
on a large number of &rest it's a clear win, but it requires modifying a lot of call/return vops and is slightly slower when the number is small
14:34:33
flip214
Would it make sense to move &rest to some heap-allocated frame instead of holding them on the stack?
14:35:49
flip214
apropos, I'd really appreciate a pair of functions that would allow to split a closure up into a code and an environment pointer, so that C callback structures that use a single (void*) argument for many functions (like a C++ vtable) can be easier handled
14:48:25
flip214
stassats: well, in this case I'm pushing multiple data items to C, and the C functions will run the callbacks at some later time, possibly one after another.
14:49:30
flip214
and instead of allocating some struct manually, storing my data in there, and passing its locked address around as a void*, I hoped that I could do that implicotly
14:52:08
flip214
instead of creating fresh (C-api) structures of closures all the time, I'd like to have one static structure with all the functions set up, and get the environment passed in via the (void*)
14:52:49
stassats
i still don't understand because i guess you're describing a solution, not the problem
14:54:04
flip214
there's a (foreign) structure that stores 8 or 10 function pointers. I allocate one, store closures in there, and call the C api with it. many, many times.
14:54:45
flip214
I would have hoped that I could instead allocate _one_ of these structures, store function pointers in there, and pass that _single_ structure to the C api _every_ time.
14:56:07
flip214
as an implicit way to pass the required state on, instead of allocating some class with the data myself
15:00:26
flip214
I'd like to avoid _manually_ allocating something to keep the state. The dynamic environment has all the information, so I'd like to pack that into a void* and send it on
15:02:44
flip214
I guess it would be more easy to explain in person.... sadly you won't be at SBCL20, but perhaps I'll get a chance at the next ELS
15:03:52
stassats
i doubt it, i'm not even close to getting how the normal closures are not suitable
15:16:01
pfdietz
Support for closure savings/loading in fasls would be really nice for some things I've tried to do.