freenode/#sicl - IRC Chatlog
Search
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