freenode/#sicl - IRC Chatlog
Search
4:44:22
beach
Besides mediocre software, the other thing I don't like is mediocre documentation. When I do `git status -s' in one sub-directory of SICL I get a T in the second column, but `man git-status' does not list T as one of the possible outputs.
4:46:23
no-defun-allowed
https://stackoverflow.com/questions/6879501/filter-git-diff-by-type-of-change#6879568 has a snippet from `man git-diff` of all places describing the letters.
4:55:01
beach
OK, I think I see what the problem is, but it required #sicl, no-defun-allowed, stackoverflow, and a second computer with a copy of the SICL repository on it to figure it out.
4:55:27
beach
Somehow, files that are symbolic links in the repository have turned into regular files.
4:56:25
no-defun-allowed
I've never checked, but the GitHub viewer shows broken symbolic links as files, just containing the pathname.
4:57:40
no-defun-allowed
I think that's how the representation could work though. If you look at the contents of those files, are they what you expect?
4:58:22
no-defun-allowed
(Not that this is what you expected at all, but do they have the contents of the linked file?)
5:00:54
beach
Yes, they are identical. Just removing the files and doing git checkout fixes the problem.
5:14:27
beach
Clearly, the software I write has defects, and the documentation is sometimes incorrect or out of date. But I am a single person, and I would think that software like GIT or Firefox would be better, given the resources at their disposal. Having said that, I think that the software that has been `released' and the documentation we produce for it, like Cluffer, Eclector, Flexichain, etc. are not too bad at all, given the resources
5:17:21
beach
I do not consider Cleavir as having been `released', since it is still being worked on. It is used by Clasp because drmeister asked to use it.
5:43:29
beach
The thread is part of the dynamic environment, so a separate register is not strictly required.
5:44:53
beach
Multiple values beyond what registers can hold can be contained there as has been suggested.
5:48:34
beach
Code that uses the floating-point register for floating-point arithmetic can just save that register temporarily.
5:49:21
beach
But since I expect most code to use integer arithmetic, or no arithmetic at all, there is a chance that this register will not have to be saved and restored very often.
5:53:18
beach
The inconvenience, of course, is that it has to be copied to a general-purpose register in order to be dereferenced.
5:56:26
beach
On the other hand, if I dedicate a general-purpose register for it, then it would very likely have to be spilled to make room for other data during the execution of a function.
6:05:08
beach
In the past I was thinking that the thread object would be accessed through the dynamic environment, like a special variable.
6:07:13
beach
And object allocation is needed for lots of stuff, including creating closures and "cells" for shared variables.
6:33:48
Shinmera
beach: Could use SSE registers instead, those would be even less likely to be used.
6:34:42
Shinmera
You might want to talk to the SBCL people though, they might have real-world based opinions on which register to pick.
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.