Wed, 17 May 2023 18:28:39 -0000 (UTC)

Related articles |
---|

[6 earlier articles] |

Re: binary search debugging of compilers cameron.mcinally@nyu.edu (Cameron McInally) (2023-05-14) |

Re: binary search debugging of compilers 864-117-4973@kylheku.com (Kaz Kylheku) (2023-05-15) |

Re: binary search debugging of compilers 864-117-4973@kylheku.com (Kaz Kylheku) (2023-05-15) |

Re: binary search debugging of compilers gah4@u.washington.edu (gah4) (2023-05-16) |

Re: binary search debugging of compilers rsc@swtch.com (Russ Cox) (2023-05-17) |

Re: binary search debugging of compilers cameron.mcinally@nyu.edu (Cameron McInally) (2023-05-17) |

Re: binary search debugging of compilers 864-117-4973@kylheku.com (Kaz Kylheku) (2023-05-17) |

Re: binary search debugging of compilers 864-117-4973@kylheku.com (Kaz Kylheku) (2023-05-17) |

Re: binary search debugging of compilers gah4@u.washington.edu (gah4) (2023-05-17) |

Re: binary search debugging of compilers spibou@gmail.com (Spiros Bousbouras) (2023-05-18) |

Re: binary search debugging of compilers rsc@swtch.com (Russ Cox) (2023-05-18) |

Re: binary search debugging of compilers 864-117-4973@kylheku.com (Kaz Kylheku) (2023-05-19) |

Re: binary search debugging of compilers 864-117-4973@kylheku.com (Kaz Kylheku) (2023-05-19) |

[6 later articles] |

From: | Kaz Kylheku <864-117-4973@kylheku.com> |

Newsgroups: | comp.compilers |

Date: | Wed, 17 May 2023 18:28:39 -0000 (UTC) |

Organization: | A noiseless patient Spider |

References: | 23-05-003 23-05-005 23-05-006 23-05-008 23-05-011 23-05-012 |

Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="57401"; mail-complaints-to="abuse@iecc.com" |

Keywords: | debug, tools |

Posted-Date: | 17 May 2023 15:06:15 EDT |

On 2023-05-17, gah4 <gah4@u.washington.edu> wrote:

*> On Monday, May 15, 2023 at 6:54:08 PM UTC-7, Kaz Kylheku wrote:*

*>*

*> (snip)*

*>*

*>> Say we have a basket of apples with a rotten smell emanating from it.*

*>> We can subdivide it, and smell one half and the other. If both halves*

*>> smell, we know we have two or more rotten apples and they ended up*

*>> in different halves. This doesn't matter. We just pick one half and*

*>> keep subdividing.*

*>*

*> But the algorithm described, at least as I remember it, doesn't test both*

*> halves.*

If the problem reproducews with the half you're testing, you assume

the misprocessed function is in that half. (There could be a bad

function in the other half also, and you could test that, but it's

unnecessary.)

If the problem deosn't reproduce in the half you're testing, you

assume the misprocessed functions lie in the other half, and

recurse on that half instead.

The algorithm will work even if every single function is miscompiled.

(And will take the same logarithmic number of steps, since we cut

in half no matter what.)

It will arbitrarily narrow it down to one, showing that even if the

compiler change is enabled for just one function, there is a problem.

That function can be investigated. Then maybe then the fix solve the

issue for the five hundred other broken functions, too.

The main problem in that situation is that the function you narrow it

down to may not be the easiest one to investigate. Say that a

three line function is broken, and a 1000 line function is broken;

the binary search finds the 1000 line function, whereas it would be

easier to investigate how the three line function is miscompiled.

There could be the following issue: among several functions that

are miscompiled, there are two: foo and bar. *Both* must be

miscompiled for the problem to reproduce, due to an interaction.

If there is a recursive subdivision such that foo and bar are in

different halves, then the problem doesn't reproduce for either half.

Therefore, when the problem fails to reproduce for the currently

tested half, it may be wise to cross-test the other half. If it also

doesn't reproduce, the halves have to be recombined and some other

approach taken, like perturbing the enumeration so that the partitioning

is done differently, or doing a slow linear elimination.

--

TXR Programming Language: http://nongnu.org/txr

Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

Mastodon: @Kazinator@mstdn.ca

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.