Subj : Re: Not debugging?
To   : comp.programming,comp.lang.java.programmer,comp.lang.lisp
From : Phlip
Date : Sun Aug 28 2005 05:55 pm

Greg Menke wrote:

> As we speak, I'm helping deal with a crash-on-reset problem on the
> production hardware that doesn't happen on the development hardware,
> plus weird edac behavior to go along with it.  Analyzing this problem
> requires a top to bottom analysis of the system will all sorts of
> inter-team documentation of whats going on.  How is an emulator going to
> help here?

The outer topic is your development environment. Yours is resisting this bug 
as we "speak".

(You also had few opportunities to _prevent_ the bug.)

The inner topic is an emulator.

> At best it will exhibit the same problems (but we still
> don't know what the problems are), at worst it will not duplicate the
> behavior.

Here's a completely unrelated topic. When you use "make menuconfig" to build 
Linux, you get a zillion options for all kinds of hardware peripherals. You 
can freely mix and match all the options, and build a stable Linux.

How could Linux possibly be stable if you activate some combination of 
options that nobody ever activated before? The odds increase as you plug in 
weird hardware combinations.

The answer is those combinations are not a zillion opportunities for bugs, 
they are a zillion forces against bugs. Each cross-constraint, passing its 
tests, reduces the odds of bugs in parallel situations. Constraint spaces 
with a high number of dimensions are naturally sparse, so a viable Linux 
kernel can only exist in very few states.

I would prefer code that passed both emulation tests and tests in real 
hardware. Cross-testing is good, even when the emulator doesn't exactly 
match the hardware. Sometimes it's good _because_ they don't match. Run such 
tests more often.

There are indeed many reasons why an emulator might not be ideal for every 
kind of embedded situation.

In _theory_, for each bug you debug in the hardware, you should force the 
emulator to exhibit the same bug before killing it.

The decision to do that should be per-bug, not per-emulator.

> It hasn't gotten us any closer in the former case, in the
> latter its worse because project management is now nervous because its
> presenting another difference from the real system yet they're (supposed
> to be) relying on it to help them test.

Ah, so you are exposing your managers to implementation details.

Pay no attention to the little emulator behind the curtain!

-- 
  Phlip
  http://www.greencheese.org/ZeekLand  <-- NOT a blog!!!

.