mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-08-18 12:29:21 +00:00
Always say "the test program", part 2.
Refer to the various "modules" of bugpoint as "debuggers", not "debugging modes" or "modules". I think this is more evocative of how they typically act, and it's shorter. Add a note about how a linker bug can crash bugpoint early. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@9257 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
parent
129e7a88b0
commit
6ff3310c49
@ -36,15 +36,15 @@ time for computer time in the compiler-debugging process; consequently, it may
|
||||
take a long period of (unattended) time to reduce a test case, but we feel it
|
||||
is still worth it. :-) <p>
|
||||
|
||||
<a name="automaticmodeselection">
|
||||
<h4>Automatic Mode Selection</h4>
|
||||
<a name="automaticdebuggerselection">
|
||||
<h4>Automatic Debugger Selection</h4>
|
||||
|
||||
<tt>bugpoint</tt> reads each <tt>.bc</tt> or <tt>.ll</tt> file
|
||||
specified on the command line and links them together into a single module,
|
||||
called the test program. If any LLVM passes are
|
||||
specified on the command line, it runs these passes on the test program. If
|
||||
any of the passes crash, or if they produce a malformed LLVM module,
|
||||
<tt>bugpoint</tt> enters <a href="#crashdebug">crash debugging mode</a>.<p>
|
||||
any of the passes crash, or if they produce malformed output,
|
||||
<tt>bugpoint</tt> starts the <a href="#crashdebug">crash debugger</a>.<p>
|
||||
|
||||
Otherwise, if the <a href="#opt_output"><tt>-output</tt></a> option was not
|
||||
specified, <tt>bugpoint</tt> runs the test program with the C backend (which
|
||||
@ -53,18 +53,18 @@ is assumed to generate good code) to generate a reference output. Once
|
||||
executing it
|
||||
with the <a href="#opt_run-">selected</a> code generator. If
|
||||
the resulting output differs from the reference output, it assumes the
|
||||
difference resulted from a code generator failure, and enters
|
||||
<a href="#codegendebug">code generator debugging mode</a>.<p>
|
||||
difference resulted from a code generator failure, and starts the
|
||||
<a href="#codegendebug">code generator debugger</a>.<p>
|
||||
|
||||
Otherwise, <tt>bugpoint</tt> runs the test program after all of the LLVM passes
|
||||
have been applied to it. If its output differs from the reference output,
|
||||
it assumes the difference resulted from a failure in one of the LLVM passes,
|
||||
and enters
|
||||
<a href="#miscompilationdebug">miscompilation debugging mode</a>. Otherwise,
|
||||
and enters the
|
||||
<a href="#miscompilationdebug">miscompilation debugger</a>. Otherwise,
|
||||
there is no problem <tt>bugpoint</tt> can debug.<p>
|
||||
|
||||
<a name="crashdebug">
|
||||
<h4>Crash debugging mode</h4>
|
||||
<h4>Crash debugger</h4>
|
||||
|
||||
If an optimizer crashes, <tt>bugpoint</tt> will try as hard as it can to
|
||||
reduce the list of passes and the size of the test program. First,
|
||||
@ -72,8 +72,9 @@ reduce the list of passes and the size of the test program. First,
|
||||
is useful when debugging a problem exposed by <tt>gccas</tt>, for example,
|
||||
because it runs over 25 optimizations.<p>
|
||||
|
||||
Next, <tt>bugpoint</tt> tries removing functions from the module, to reduce the
|
||||
size of the test program. Usually it is able to reduce a test program
|
||||
Next, <tt>bugpoint</tt> tries removing functions from the test program, to
|
||||
reduce its
|
||||
size. Usually it is able to reduce a test program
|
||||
to a single function, when debugging intraprocedural optimizations. Once the
|
||||
number of
|
||||
functions has been reduced, it attempts to delete various edges in the control
|
||||
@ -85,36 +86,37 @@ reproduce the failure with <tt><a href="opt.html">opt</a></tt> or
|
||||
<tt><a href="analyze.html">analyze</a></tt>.<p>
|
||||
|
||||
<a name="codegendebug">
|
||||
<h4>Code generator debugging mode</h4>
|
||||
<h4>Code generator debugger</h4>
|
||||
|
||||
The code generator debugger attempts to narrow down the amount of code that is
|
||||
being miscompiled by the <a href="#opt_run-">selected</a> code generator. To do
|
||||
this, it takes the LLVM program and partitions it into two pieces: one piece
|
||||
this, it takes the test program and partitions it into two pieces: one piece
|
||||
which it compiles with the C backend (into a shared object), and one piece which
|
||||
it runs with either the JIT or the static LLC compiler. It uses several
|
||||
techniques to reduce the amount of code pushed through the LLVM code generator,
|
||||
to reduce the potential scope of the problem. After it is finished, it emits
|
||||
two bytecode files (the "test" [to be compiled with the code generator] and
|
||||
"safe" [to be compiled with the C backend] modules), and instructions for
|
||||
reproducing the problem. This module assume the C backend produces good
|
||||
code.<p>
|
||||
two bytecode files (called "test" [to be compiled with the code generator] and
|
||||
"safe" [to be compiled with the C backend] respectively), and instructions for
|
||||
reproducing the problem. The code generator debugger assumes that the C
|
||||
backend produces good code.<p>
|
||||
|
||||
If you are using this mode and get an error message that says "Non-instruction
|
||||
If you are using the code generator debugger and get an error message that
|
||||
says "Non-instruction
|
||||
is using an external function!", try using the <tt>-run-llc</tt> option instead
|
||||
of the <tt>-run-jit</tt> option. This is due to an unimplemented feature in the
|
||||
code generator debugging mode.<p>
|
||||
code generator debugger.<p>
|
||||
|
||||
<a name="miscompilationdebug">
|
||||
<h4>Miscompilation debugging mode</h4>
|
||||
<h4>Miscompilation debugger</h4>
|
||||
|
||||
The miscompilation debugging mode works similarly to the code generator
|
||||
debugging mode. It works by splitting the program into two pieces, running the
|
||||
optimizations specified on one piece, relinking the program, then executing it.
|
||||
The miscompilation debugger works similarly to the code generator
|
||||
debugger. It works by splitting the test program into two pieces, running the
|
||||
optimizations specified on one piece, linking the two pieces back together,
|
||||
and then executing the result.
|
||||
It attempts to narrow down the list of passes to the one (or few) which are
|
||||
causing the miscompilation, then reduce the portion of the program which is
|
||||
being miscompiled. This module assumes that the selected code generator is
|
||||
working properly.<p>
|
||||
|
||||
causing the miscompilation, then reduce the portion of the test program which is
|
||||
being miscompiled. The miscompilation debugger assumes that the selected
|
||||
code generator is working properly.<p>
|
||||
|
||||
<a name="bugpoint notes">
|
||||
<h4>Advice for using <tt>bugpoint</tt></h4>
|
||||
@ -123,14 +125,14 @@ working properly.<p>
|
||||
non-obvious ways. Here are some hints and tips:<p>
|
||||
|
||||
<ol>
|
||||
<li>In code generator and miscompilation debugging modes, <tt>bugpoint</tt> only
|
||||
<li>In the code generator and miscompilation debuggers, <tt>bugpoint</tt> only
|
||||
works with programs that have deterministic output. Thus, if the program
|
||||
outputs the date, time, or any other "random" data, <tt>bugpoint</tt> may
|
||||
misinterpret differences in these data, when output, as the result of a
|
||||
miscompilation. Programs should be temporarily modified to disable
|
||||
outputs that are likely to vary from run to run.
|
||||
|
||||
<li>In code generator and miscompilation debugging modes, debugging will go
|
||||
<li>In the code generator and miscompilation debuggers, debugging will go
|
||||
faster if you manually modify the program or its inputs to reduce the
|
||||
runtime, but still exhibit the problem.
|
||||
|
||||
@ -147,9 +149,13 @@ non-obvious ways. Here are some hints and tips:<p>
|
||||
<br>to get a copy of <tt>bugpoint</tt>'s output in the file
|
||||
<tt>bugpoint.log</tt>, as well as on your terminal.<p>
|
||||
|
||||
<li><tt>bugpoint</tt> cannot debug problems with the linker. If
|
||||
<tt>bugpoint</tt> crashes before you see its "All input ok" message,
|
||||
you might try <tt>llvm-link -v</tt> on the same set of input files. If
|
||||
that also crashes, you may be experiencing a linker bug.
|
||||
|
||||
</ol>
|
||||
|
||||
|
||||
<h3>OPTIONS</h3>
|
||||
|
||||
<ul>
|
||||
|
Loading…
Reference in New Issue
Block a user