[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [csmith-dev] Any tricks for narrowing down GCC bugs to avoid duplications?



On Thu, Apr 21, 2011 at 9:40 PM, John Regehr <regehr@cs.utah.edu> wrote:
> Your bug report is better than mine because it has a reduced test case!  I
> used to try to reduce resource hog bugs but it's so painful that I stopped.
>  So nice job :).

With a list of functions, and a list of globals with their types, it
would be possible to script gdb to display, each time a function is
entered or exited, the name of the function and the values of all
globals. This makes finding the miscompiled expression much more
comfortable without requiring any compilation chain change that might
hide the bug. When you have the types of variables on the side, you do
not need to have compiled with debug information; you can use e.g:

(gdb) display (int[5])t
1: (int [5]) {<data variable, no debug info>} 4294971488 = {1, 2, 3, 4, 5}

A couple of regexps to eliminate compilation-dependent addresses, and
we would have traces for all executables that should usually be
identical, and could be scanned for first difference.

This does not work if compilers may move computations across function
calls when the code of these functions is available. Do they do that?
Am I missing another difficulty?

Pascal