From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 28702 invoked from network); 5 May 2020 22:00:29 -0000 Received-SPF: pass (minnie.tuhs.org: domain of minnie.tuhs.org designates 45.79.103.53 as permitted sender) receiver=inbox.vuxu.org; client-ip=45.79.103.53 envelope-from= Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 5 May 2020 22:00:29 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 7A9E39CA9F; Wed, 6 May 2020 08:00:28 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id ACCFE9CA1C; Wed, 6 May 2020 08:00:03 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="RhEfJk/W"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 93F479CA1C; Wed, 6 May 2020 08:00:00 +1000 (AEST) Received: from mail-qt1-f194.google.com (mail-qt1-f194.google.com [209.85.160.194]) by minnie.tuhs.org (Postfix) with ESMTPS id 332749C9B7 for ; Wed, 6 May 2020 07:59:59 +1000 (AEST) Received: by mail-qt1-f194.google.com with SMTP id w29so3462321qtv.3 for ; Tue, 05 May 2020 14:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e0LJNAWLE8oG6jou6gqZFRjZ8svMMDIXXce6MPTDKbQ=; b=RhEfJk/WX/AyIdKhmFJnfsqDKawA1VRYcHmkke4Q4iupwMKL84hT5KIz2xXLBlsWvf yHL6y+OlEYCqDaXzWDMQz7LDQE98By/g+HX0Hy5NFef/MkOu7ZddvC4FFh/IMp0DTnAt SfGzkAChdk21MNAqWg6gh+vV2QTuuN4TY4WqdpgZj4FUlkyUan9B7IzRsMvy8RRZYI68 Ndgext+AQrTpfNY8+Vpx/WUcuf38qEtYDGIBJ8sXOv49a7bITLcbHeudjhSz+7AcLb4Y 5MV9/3SCQAvAmry3Yms7BRq8Xt7qGMj2HkSUbLf2V4EBrVcLzWwNtKmaxBiIxnpYMcjh Ta2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e0LJNAWLE8oG6jou6gqZFRjZ8svMMDIXXce6MPTDKbQ=; b=LCy83ok7YuPRSdVlGLK/TSS0500sujOKGtgD4sAyRrw2cTp3eeeFdl31IOw3QGggbZ Z7FbcvQkAHixsB9OEEnOmE+M0j5IiK685+kFm9lyuJO2x0DbwIcQNRgFXBxde/O59zR2 Pm1T9JRMJjx/mq4s3t41rYdOrg55skQbynNaUcqPNEBlMSVXlSVj692l3JPX4YrjeMZ9 cvLhf/7DNVxSYg02KggMQ7MYo8EwVmK5hLmSoqKNBCPZN/MGD2XMfQsRbM+nyKC0gQAe ErZv22SFnMEgTXg6ujkG9fK7xkLThOIpDYPFE+5IUyoxBURVj5efzIdhMXmEjFXqkNfm xYNA== X-Gm-Message-State: AGi0PuZ69gFiliGSUVRKYSV7R/dA2EDbk8AR02zS5yy7WG5TO7NvAAlB podW9eMygarSCs9/GR9MQO6au6m4ZEvS6fhNUpY= X-Google-Smtp-Source: APiQypKDYf/3T7bFA2CHdztd22zv2wv5FqoZsA1v2Tk9FbvPh3NClKVaHcmr413ANNDtiCDjjMaifSdeFEl30Zlt7pE= X-Received: by 2002:ac8:4e88:: with SMTP id 8mr5078138qtp.82.1588715998287; Tue, 05 May 2020 14:59:58 -0700 (PDT) MIME-Version: 1.0 References: <2F4C604D-F01C-4A82-948A-7E77093B48A1@planet.nl> <21F16C75-62AB-422A-A43F-981407E11434@planet.nl> <8D548BBE-AB7A-457E-87F8-F3718A9AC4B7@acm.org> In-Reply-To: From: Dan Cross Date: Tue, 5 May 2020 17:59:22 -0400 Message-ID: To: Paul Winalski Content-Type: multipart/alternative; boundary="000000000000ba235205a4edc48a" Subject: Re: [TUHS] DEC Compilers (was: Re: SDB debugger X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000ba235205a4edc48a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 5, 2020 at 1:37 PM Paul Winalski wrote: > On 5/4/20, Win Treese wrote: > > > > Andy Payne, a recent hire at the lab, had been an intern in DEC=E2=80= =99s > > semiconductor group, where he had worked on randomized testing for > hardware > > verification. With all the compilers available, he decided to hack up a > > program to generate random small C programs with computable expected > > outputs. His program then compiled the random code with each compiler a= nd > > tested the result. After finding a number of bugs this way, he got tire= d > of > > submitting the bug reports, and changed his program to write and submit > the > > bug reports automatically. > > > > This caused a little bit of consternation with some of the compiler > teams at > > first. > > I remember that very well. IIRC it was called fuzz testing, and > indeed it was controversial, for the reasons Bill McKeeman discusses > in his paper. [1] On the one hand, compiler developers said, "nobody > would ever write something like that--we can't waste our time on these > issues when there are real bugs waiting to be fixed." On the other > hand, some of the bugs that fuzz testing turned up provoked reactions > such as, "OMG! THAT caused the compiler to crash?" I think the > turning point was when fixing one of the fuzz testing bugs also fixed > an obscure and hard-to-debug customer problem. Intel's C and Fortran > compiler team has also used random testing technology. > Ah, very cool. The same approach has come into favor again recently. I've dealt personally with https://github.com/google/syzkaller, which is a kernel fuzzer that generates random inputs to system calls and detects e.g. panics. It's a neat approach. - Dan C. > [1] https://www.hpl.hp.com/hpjournal/dtj/vol10num1/vol10num1art9.pdf > > -Paul W. > --000000000000ba235205a4edc48a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, May 5, 2020 at 1= :37 PM Paul Winalski <paul.wi= nalski@gmail.com> wrote:
On 5/4/20, Win Treese <treese@acm.org> wrote:=
>
> Andy Payne, a recent hire at the lab, had been an intern in DEC=E2=80= =99s
> semiconductor group, where he had worked on randomized testing for har= dware
> verification. With all the compilers available, he decided to hack up = a
> program to generate random small C programs with computable expected > outputs. His program then compiled the random code with each compiler = and
> tested the result. After finding a number of bugs this way, he got tir= ed of
> submitting the bug reports, and changed his program to write and submi= t the
> bug reports automatically.
>
> This caused a little bit of consternation with some of the compiler te= ams at
> first.

I remember that very well.=C2=A0 IIRC it was called fuzz testing, and
indeed it was controversial, for the reasons Bill McKeeman discusses
in his paper. [1]=C2=A0 On the one hand, compiler developers said, "no= body
would ever write something like that--we can't waste our time on these<= br> issues when there are real bugs waiting to be fixed."=C2=A0 On the oth= er
hand, some of the bugs that fuzz testing turned up provoked reactions
such as, "OMG!=C2=A0 THAT caused the compiler to crash?"=C2=A0 I = think the
turning point was when fixing one of the fuzz testing bugs also fixed
an obscure and hard-to-debug customer problem.=C2=A0 Intel's C and Fort= ran
compiler team has also used random testing technology.

Ah, very cool. The same approach has come into favor again = recently. I've dealt personally with=C2=A0https://github.com/google/syzkaller, which is a kern= el fuzzer that generates random inputs to system calls and detects e.g. pan= ics. It's a neat approach.

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 - Dan C.

> [1] https://www.hpl.hp.com/hpjo= urnal/dtj/vol10num1/vol10num1art9.pdf

-Paul W.
--000000000000ba235205a4edc48a--