Re: binary search debugging of compilers

>From: Larry McVoy <lm@mcvoy.com>
>Date: Mon, May 15, 2023 at 1:57 PM
>Subject: Re: history of source control binary search for debugging
>
>Good to hear from you Russ.
>
>I'm pretty sure I "invented" that idea, which means I hadn't seen it before.
>All I was doing was using the fact that binary search is log(n). And giving
>non-kernel people a way to do some grunt work and then get it close and
>then hand that off to the kernel people.
>
>But note that the BUG-HUNTING was using snapshot, not source management.
>BitKeeper hadn't been invented yet and the other source management systems
>sucked because they were reproducible only at tagged points. At least
>that was true of CVS.


With cvs update -D, one can select a date and update the tree to that
specific date. Indeed, I've been known to use '1 day ago', ... '50
days ago' and binary search that way as well. Nice interface as you
only have to deal with changing a single number. And the granularity
in days is a nice metric. It gets you down to a day or two and then
you dig in from there. Further, with cvs, you could update only parts
of the tree if you suspect which part might be failing. Front end,
loop unrolling and so on.


Another technique I've used to is save off part of the compiler
(cc1/cc1plus) binary from the nightly build system, and then when you
want state on a bug, you simply for i in */cc1; do test $i; done and
then you get a total view of that code against all the compilers. You
can see bugs pop in and out, or if they are simple, always worked
before, and never after.


These methods are so basic that there is no need to write them down.
I've been using such techniques longer than linux has been around.
:-)

Return to the comp.compilers page.
Search the comp.compilers archives again.