nios-build debug option

Can anybody tell me what is the effect of debug option in nios-build
command to the original program? What's the usage of debug script that
generated in the command?

I'd connected my processor as a user defined peripheral to nios system
module through SOPC Builder. The system performs corectly only when I
use debug option during nios-build- to compile the C/C++ source code.
Without the debug option, the data that fetched from my processor will
be the data before I initiate the data transaction. I'm suspect that
is the timing problem. But the system works correctly only after the
debug option is used.

"Maxlim" <maxlim79@hotmail.com> wrote in message
news:a6140565.0401140148.3e3c984b@posting.google.com...
> Can anybody tell me what is the effect of debug option in nios-build
> command to the original program? What's the usage of debug script that
> generated in the command?
>
> I'd connected my processor as a user defined peripheral to nios system
> module through SOPC Builder. The system performs corectly only when I
> use debug option during nios-build- to compile the C/C++ source code.
> Without the debug option, the data that fetched from my processor will
> be the data before I initiate the data transaction. I'm suspect that
> is the timing problem. But the system works correctly only after the
> debug option is used.

Turning on the debug option will do two things to the generated code - it
will include debug information in the object files (so that a debugger can
match up variables and addresses, and object code and source code), and it
will turn off (or at least lower) the optomisation levels, making the
generated code more debugger-friendly (trying to debug highly optomised code
can sometimes be very confusing).  The chances are, therefore, that your
problem is that your code works with low optomisations and fails on high
optomisations.  This means either the compiler's optomiser is broken
(possible, but unlikely), or your code is making unwarented assumptions
about the generated object code.  Very often, this can be solved by correct
use of "volatile".  For example, consider code such as:

void generateSquareWave(void) {
    int i;

    while (1) {
        outputPort = 0xffff;
        for (i = 0; i < 1000; i++) ;        // Wait a bit
        outputPort = 0x0000;
        for (i = 0; i < 1000; i++);        // Wait a bit
    };
}

Many people would think that this generates a slow square wave.  With
optomisation turned off, it probably will.  But with high optomisation, the
compiler will notice that the for loops don't actually do anything useful -
they simply waste time, which is exactly what the optomiser is trying to
avoid.  It will therefore simply drop them, giving you an extremly fast
square wave.  The simple solution to this is to make "i" a "volatile int",
which tells the optomiser that you want to keep every read and write to the
variable, and thus the delays stay in.

Other typical effects are that the optomiser will often re-arrange code to
make it smaller or faster, even if that means changing the order in which
data is read or written (or even *if* it is read or written).  Again,
"volatile" will help you enforce the correct order.