freenode/#sicl - IRC Chatlog
Search
8:10:51
beach
I have also been looking for a register in which a single bit indicates whether a thread is being debugged. I can use one bit in the same register or I can use another SSE register. That would make the test for being debugged fast enough that it should only have a very small impact on a thread that is not being debugged.
8:14:24
Shinmera
That stuff, if I remember correctly, runs with almost zero overhead, which made me wonder whether it could be repurposed
8:15:23
beach
And I don't even know what tracing and profiling stuff you are referring to, since I am not that familiar with the Linux kernel.
8:17:01
Shinmera
I'm not sure either, I just faintly remember a talk about how they achieved high performance profiling.
8:30:45
beach
I don't know, but it looks like kernel tracepoints are obtained through explicit instrumentation.
9:05:30
beach
My idea for SICL, in case someone missed it, is to have a 3-stage test for each possible breakpoint/tracepoint (when the code is compiled with a high value of DEBUG). In stage 1, a flag is tested to see whether the current thread is being debugged at all. Most threads are not, so this test will then skip the remaining stages, with only a minimal slowdown being the result.
9:05:37
beach
If the thread is being debugged, a small-ish (maybe 64 entries, so that the table fits in a word) Boolean table is being consulted, using the current value of the program counter, modulo the size of the table. If the table contains 0, then, the third stage is being skipped, resulting in a small slowdown only for breakpoints with the same modulo value as one that is "active".
9:05:39
beach
Finally, if the table contains 1, the debugger is consulted to determine whether this value of the program counter requires special treatment. Only a small number of PC values will need to do all 3 stages.
11:15:36
beach
The more I think about it, the more I am impressed by this original idea by scymtym about how the debugger and the debuggee communicate.
11:15:43
beach
Standard wisdom is that the debugger has access to the internal state of the debuggee, and can alter data and control flow relatively arbitrarily. But that model is inherently unsafe. The debugger can then get access to anything that the debuggee has access to, so it can do basically anything.
11:15:58
beach
The model suggested by scymtym (I am paraphrasing; not the literal words used by scymtym) is that the debuggee proposes a bunch of services, depending on the place where it has stopped.
11:16:06
beach
The role of the debugger is merely to show these services to the user and to provide a convenient interface for the user to choose one of the services offered.
11:16:07
beach
With this model, the debuggee only offers services that are safe, and the debugger has no way of proposing any other service.
11:18:16
beach
I guess I should document this basic idea and how it differs from standard wisdom. Probably in the Clordane introduction.
12:58:49
Bike
it would be kind of neat to be able to debug without super permissions. though i don't know how often it would actually come up
13:02:07
beach
You seem to agree with nyef, who protest every time I suggest something safe, because his thing is to debug compilers.
13:15:39
Shinmera
Bike: capabilities means that you can't access anything unless the OS gives it to you as part of a user action.
13:15:59
Shinmera
Eg you can't access the file system without going through an OS file picker that the user interacts with
13:17:58
Shinmera
It's already employed on things like Android, where the application has to either explicitly request a file open, or declare which locations/capabilities it needs in the package, which the user has to agree to.
13:18:13
Shinmera
The user can also restrict and deny certain capabilities, which makes associated calls fail.
13:19:10
Bike
so you'd have a different capability like accessing specifically the tmp directory or some internal cache, and then requiring the file picker seems more reasonable
13:19:48
Shinmera
Typically you're given stuff like caches and temp storage, as well as persistent storage out of the box.
13:20:09
Shinmera
Since they're so commonly needed. You just don't know where/how that stuff is really stored.
13:20:11
scymtym
i think there is also a more technical meaning where having a capability means having the function or object pointer that implements the functionality
13:23:22
Bike
i just meant that since you're talking about a debugger that can't do absolutely everything like the common ones now can, it wouldn't be so much of a security hole
13:24:17
beach
shka__: Yes, I know about capability-based security. Eros was based entirely on that.
13:32:20
beach
scymtym: Did you just come up with this model, or did you have inspiration from somewhere?
13:35:24
beach
Over time, I think we should come up with a list of characteristics of this model, and especially characteristics that set it apart from standard wisdom.
13:37:09
scymtym
beach: i don't remember. i have probably read about similar designs for remote (like, actual remote, not just out-of-process) debugging
13:37:49
shka__
i think that this may be valuable model because of private data potentially stored in the process
13:40:17
beach
Of course. I might be tempted to make a version of SICL that is as unsafe as other Common Lisp implementations. But I want to try the safe one first.
13:40:28
scymtym
i didn't really think about safety and security benefits too much. it just seemed like a convenient way of suspending and controlling the thread being debugged
13:43:08
beach
So, if we add to that model the fact that we have a thread debugging another thread in the same process, and that it will be possible to debug code even if it is used directly by the debugger itself, I think we have a list of features that make this thing unusual, if not unique.
13:43:56
beach
So we can set a breakpoint in SHARED-INITIALIZE or MAKE-INSTANCE despite the fact that the debugger will likely use those.
13:53:18
beach
But we can force a call to the CAR function when an application is compiled with a high value of the DEBUG OPTIMIZE quality.
13:55:06
beach
Conditional breakpoints will be a breeze. If the debuggee communicates the values of all its live variables to the debugger, then the debugger can add a test to the breakpoint and instruct the application to continue if the test does not return true.
13:56:16
beach
If the debuggee communicates a value that is mutable, we would have to prevent the debugger from being able to mutate it.
13:57:47
beach
But I must give a lot more thought to including capabilities in SICL from the start if that is the path we are going to take.
14:02:46
beach
The preliminary idea is to reserve a few (3 or 4) upper bits in each pointer for permissions.
14:04:14
beach
The object store has an access-control list for every object. When some thread (with some owner) accesses an object from the object store, the access-control list is checked, and according to the permissions for that particular owner, a capability is returned that reflects those permissions.
14:05:03
beach
Things like STANDARD-INSTANCE-ACCESS and (SETF STANDARD-INSTANCE-ACCESS) check the appropriate bit before granting the operation.
14:59:27
Bike
which could be different from the definition, e.g. a let with bindings on different lines would have a different location for each variable, but the enter-instruction only has one origin
15:05:22
beach
And I think of those locations as resulting in special HIR instructions to mark the start of the evaluation and the end of the evaluation of an expression.
15:06:34
beach
So the defining instruction for a particular lexical location is somewhere in such an interval.
15:12:19
beach
So I guess there is no such thing as a unique intrinsic location associated with a particular datum the way there is with an instruction.
15:13:52
beach
But that might not be the defining place, where I use `define' as in compiler theory.
15:14:33
beach
So I guess if you absolutely want one single location, the initial binding would be it.
15:16:06
beach
I am thinking of a GUI where the programmer hovers the pointer over an occurrence of a variable.
15:16:42
beach
And all possible defining occurrences turn red, whereas all using occurrences turn green, taking into account UD and DU chains that it.
15:16:47
Bike
here's why i'm actually asking: llvm lets me associate a variable with one source location. a file and a line. so the binding seems the most natural to me. However, I've never actually wanted to jump to the source of a lexical variable or anything before, so I'm not sure about the use case.
15:17:59
Bike
for some cases I do understand, like for a special variable I'd want slime M-. to go to the defvar or defparameter.
15:18:59
Bike
well maybe it's not actually... that's just the point where lisp is told it's a special variable, and a binding is where it's told something is a lexical variable
15:21:00
Bike
for a use def chain it might make more sense to reconstruct the information from context rather than record it at every location? i don't know
15:22:12
beach
I am thinking like I think you do, i.e. figure out the instructions that define and use the location.
15:25:01
beach
I am only at the very beginning of my ideas, but it did seem wrong to me to just propagate locations from ASTs to HIR. It was when I discovered that a particular value of the program counter can correspond to several source locations that I started rethinking stuff.
15:27:10
beach
When I contemplate stuff like that, I try to start with the kind of things that the programmer might do when he or she is running the debugger on some code, and by "debugger", I mean much more than staring at a backtrace when things go wrong.
15:30:11
beach
But if you have little experience with using good debuggers, it is hard to imagine such use cases.
15:30:31
Bike
i suppose that's the problem, that's the most i've ever used a debugger for, really. backtrace and occasionally evaluating an expression in context
15:33:04
beach
I was pretty good with GDB at the time, and even though it is an excellent debugger, it did not teach me anything about the visual feedback that can be given to the programmer when a GUI is used.
15:35:01
beach
You are in good company. What passes for a "debugger" in #lisp is exactly that, i.e. staring at backtraces when things go wrong.
15:36:57
beach
I would like to say things like "Stop in MAKE-INSTANCE when an attempt is made to create an instance of class <mumble> and the initarg <mumble> is not given.
15:39:38
beach
I often find myself wanting to do that, only to discover that my tools are letting me down.
16:02:14
scymtym
something like that can often be accomplished with non-standard extensions to TRACE, but it is rarely worth the trouble