CS152: Computer Architecture and Engineering
CIS 501 is in many ways a class about debugging
Copyright By PowCoder代写 加微信 powcoder
9 Rules for Debugging (c/o )
www.debuggingrules.com
Understand the system
Make it fail
Quit thinking and look
Divide & conquer
Change one thing at a time
Keep an audit trail
Check the plug
Get a fresh view
If you didn’t fix it, it ain’t fixed
goal: think about debugging as a scientific process
instead of a random one
my bug: Lab 4 .ctrace file generation
solution code was generating lots of X values, failing tests
1. Understand the system
Need to know how system is supposed to behave
understand the specification
e.g., LC4 CMP instruction treats inputs as signed
while CMPU treats them as unsigned
Don’t go overboard: don’t need to know every detail of the ZedBoard for this class
maybe X signals are OK, represent legitimate don’t-cares
need to understand semantics of $fdisplay() with X signals
need to understand when to sample the debug outputs – 4-minicycles per megacycle
2. Make it fail
Can’t debug something that is not repeatable
Bugs that are reliably triggered are really great!
Almost as good as having no bug in the first place
If steps to reproduce are complicated, consider scripting
Lab 4: very reproducible
3. Quit thinking & look
See what the system is actually doing
Staring at code is typically not an efficient use of your time
sometimes documentation is wrong
Developing hypotheses about a bug is good
but you need to test them!
Debuggers are great
they show you what is actually going on
printf/$display() is ok
faster to start with
upgrade to debugger when things get more complicated
sometimes printf is all you have
sometimes you don’t even have printf!
Lab 4: decided to check which signals have X values: test_regfile_in and test_new_nzp_bits
* using Vivado debugger, I could see that values are X for the whole megacycle
** negates sampling-at-wrong-time theory
4. Divide & conquer
Most systems have different processing steps
“garbage in, garbage out”
Try to determine where the garbage begins
E.g., if I have an X wire after
Lab 4: test_regfile_in and test_new_nzp_bits X signals were clues
* where do these signals come from?
5. Change One Thing at a time
If you only follow one rule, this is probably the one!
If multiple things have changed, how do you know which one is responsible for a behavior change?
git is helpful: use branches, stash changes, or revert
maybe a change introduced a new bug!
Lab 4: I had rewritten the testbench, so I went back to the old one
* the solution code fails the original tests! That didn’t happen before!
6. Keep an audit trail
track the One Thing that changed
what was changed
what I expected to happen
what actually happened
sometimes these changes are useful later on!
audit log format
can be very informal, 1-2 sentences often suffices
text files, google doc, Github issues
Lab 4: I did! Helped with determining the bug (and also with telling this story)
audit trail + git showed me that I had also changed the divider code to use the / operator
divider passed the divider tests, but caused a failure in the larger pipeline design
7. Check the plug
Question your assumptions
are you measuring what you think you are?
Are you running the code you think you are?
maybe the file isn’t saved, or it’s in another directory
add a printout, or change the output in a clear way
does your change have the expected effect?
Lab 4: I assumed I hadn’t changed any code in the processor – but I had!
8. Get a fresh view
Talk to someone about your problem
go to office hours
or talk to a domain expert or colleague
Take some time off from the problem
your brain will keep working in the background
9. If you didn’t fix it…it ain’t fixed
problems don’t magically go away
something changed!
if “the same code works for me” but not you, then it’s not the same!
often, our scope for the problem is too small
When you think something is fixed, revert the fix
see that it fails again!
this provides strong evidence that the fix is responsible
Lab 4: I could reliably induce/fix the problem by changing the divider code
0xA. Conduct a post-mortem
After the bug is fixed, don’t just go onto the next bug!
Take time to think about:
Were there debugging rules that were helpful?
Were there debugging rules that I ignored, but shouldn’t have?
Lab 4: I spent too much time on “exciting hypotheses” like $fdisplay() semantics and timing glitches. This distracted me from getting to the rather mundane root cause more quickly.
/docProps/thumbnail.jpeg
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com