From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.devel Subject: Re: Patches for wip-rtl Date: Sun, 21 Apr 2013 11:23:40 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b15b17da0e0c704dae08a97 X-Trace: ger.gmane.org 1366557847 13704 80.91.229.3 (21 Apr 2013 15:24:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Apr 2013 15:24:07 +0000 (UTC) To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Apr 21 17:24:11 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UTw7d-0003bO-HN for guile-devel@m.gmane.org; Sun, 21 Apr 2013 17:24:09 +0200 Original-Received: from localhost ([::1]:60702 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTw7c-0004Jy-QP for guile-devel@m.gmane.org; Sun, 21 Apr 2013 11:24:08 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:55119) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTw7W-0004Jn-Jc for guile-devel@gnu.org; Sun, 21 Apr 2013 11:24:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UTw7V-0003hQ-8Z for guile-devel@gnu.org; Sun, 21 Apr 2013 11:24:02 -0400 Original-Received: from mail-pd0-f176.google.com ([209.85.192.176]:48774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTw7U-0003hK-Vd for guile-devel@gnu.org; Sun, 21 Apr 2013 11:24:01 -0400 Original-Received: by mail-pd0-f176.google.com with SMTP id r11so3049455pdi.35 for ; Sun, 21 Apr 2013 08:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=3hnTgM+TcoUa2/VqV0bb/dIYvWOBmSI2Qdyoe3WCEt4=; b=kiKvlUfasal3Las1Cz/oI3EytBxEW1zYpWWLVwpAwC2QfYT05/4cEd8lfcSyg85zNQ NqJfpjgLYJ0lNAWlnpywa9pApovL+Fh62iry4vyXm/5I5tvxOU0rEF6MCaMxiUV2tpYW X3t7Tv4CkqYf5T6fR+1RFr2H4Xuj0YnyM+utGKNIETmhRaKxPfGOSt3E+8X4b8v5dbgc UAwbTbPMC/Nepze5iTbCJ96HN+xKC3Mt1nAImEf+C5VnHai5s7N3hESUDfBtlWXBh+Pe nxkKaKAQrSM/qe9FAAm0d4r6vEwK6l+iOvfDb8MeuU+CCE7tF1M1X8CCANmho+4g3LZE h93A== X-Received: by 10.68.200.10 with SMTP id jo10mr28239333pbc.53.1366557840169; Sun, 21 Apr 2013 08:24:00 -0700 (PDT) Original-Received: by 10.68.7.9 with HTTP; Sun, 21 Apr 2013 08:23:40 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: IMtdGOOV-OLzTxRwF5rWUJri5_s X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.192.176 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:16283 Archived-At: --047d7b15b17da0e0c704dae08a97 Content-Type: text/plain; charset=ISO-8859-1 Hello, Please don't worry about the last part of that message. I realized I can test the nargs value by (ab)using the assert-nargs-ee instruction. On a related note, there's a certain piece of code in vm.c that is not robust in the face of a corrupt nargs. Specifically, if you call vm_error_wrong_num_args (vm.c:518 in wip-rtl) with nargs=-1, guile will segfault. We could fix this, but I'm inclined to leave it as it is, because this can only happen if nargs is corrupted by some earlier call, and I think the right approach is to test the VM enough that nargs doesn't get corrupted. Does that sound reasonable? If not, it should be simple to insert some check there the nargs is big enough not to corrupt anything. Noah On Sat, Apr 20, 2013 at 7:30 PM, Noah Lavine wrote: > Hello, > > I've attached three patches for wip-rtl. The first is somewhat different > than the other two: it fixes an error that occurred when moving the linker > to its own file. (system vm rtl) and (system vm linker) both contain a > function called link-string-table, and (system vm rtl) was calling the > wrong one, which made rtl.test fail. I solved this with an @-reference. > > The second two provide better VM errors when box-ref and box-set! are > called on something that is not a variable. In particular, they throw an > exception instead of aborting. This could occur in user code, if the user > wants to hand-write RTL code, but it's also very useful in trying a new > compiler implementation. The first patch handles box-ref, and the second > handles box-set!. Also note that I had to add a new type of exception to > (test-suite lib) to catch these errors. > > Lastly, I'd like to ask for ideas on how to test for errors in VM > instructions that don't cause immediate problems, but do put the VM in an > inconsistent state. I know of a collection of these errors, and while I > could fix them, I'd rather fix them and add a test for them. I can think of > two possibilities off the top of my head: 1) add Scheme accessors for VM > state (I don't think mutators are necessary for now) or 2) write the tests > in C instead of Scheme. > > I'd prefer option 1, mostly because I think that making the VM state more > explicit is a good direction to go in anyway - eventually it would be great > if the debugger could print the contents of registers, and that would > require VM introspection anyway, so I think starting now is good. > > What do other people think of the patches and the ideas? > > Best, > Noah > --047d7b15b17da0e0c704dae08a97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

Please don't worry = about the last part of that message. I realized I can test the nargs value = by (ab)using the assert-nargs-ee instruction.

On a related not= e, there's a certain piece of code in vm.c that is not robust in the fa= ce of a corrupt nargs. Specifically, if you call vm_error_wrong_num_args (v= m.c:518 in wip-rtl) with nargs=3D-1, guile will segfault. We could fix this= , but I'm inclined to leave it as it is, because this can only happen i= f nargs is corrupted by some earlier call, and I think the right approach i= s to test the VM enough that nargs doesn't get corrupted. Does that sou= nd reasonable? If not, it should be simple to insert some check there the n= args is big enough not to corrupt anything.

Noah


On Sat, Apr 20, 2013 at 7:30 PM, Noah Lavine &= lt;noah.b.lavi= ne@gmail.com> wrote:
He= llo,

I've attached three patches for wip-rtl. The first is somew= hat different than the other two: it fixes an error that occurred when movi= ng the linker to its own file. (system vm rtl) and (system vm linker) both = contain a function called link-string-table, and (system vm rtl) was callin= g the wrong one, which made rtl.test fail. I solved this with an @-referenc= e.

The second two provide better VM errors when box-ref and box-set!= are called on something that is not a variable. In particular, they throw = an exception instead of aborting. This could occur in user code, if the use= r wants to hand-write RTL code, but it's also very useful in trying a n= ew compiler implementation. The first patch handles box-ref, and the second= handles box-set!. Also note that I had to add a new type of exception to (= test-suite lib) to catch these errors.

Lastly, I'd like to ask for ideas on how to test for errors i= n VM instructions that don't cause immediate problems, but do put the V= M in an inconsistent state. I know of a collection of these errors, and whi= le I could fix them, I'd rather fix them and add a test for them. I can= think of two possibilities off the top of my head: 1) add Scheme accessors= for VM state (I don't think mutators are necessary for now) or 2) writ= e the tests in C instead of Scheme.

I'd prefer option 1, mostly because I think that making the VM stat= e more explicit is a good direction to go in anyway - eventually it would b= e great if the debugger could print the contents of registers, and that wou= ld require VM introspection anyway, so I think starting now is good.

What do other people think of the patches and the ideas?

<= /div>Best,
Noah

--047d7b15b17da0e0c704dae08a97--