Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
12 years ago

Lacks of logic in DS-5 work processes

I propose public here a deficiences in "intuitive" working with DS-5 AE.

May be improved faster...

My claims is in general for Debug:

1. Not enough point to variable and see it value in small popup window, displays it definition. For edit text this may be rightly, or in Debug perspective -- error.

2. If start edit text upper than green line of current debug execution, the green selection creep to near lines. After Ctrl-S returns back to normal position.

3. Debug breakpoints in new debug session is disappear or disabled from previous run.

4. If sleep my PC with opened DS-5 and there source files, readed from net mapped disks (T: for example on near PC) and power on it back (another PC not repowered), many files is closed with messages about inaccessibility. Other editors is not so nagging.

5. Sometimes after pressing F6 (step over) execution stops inside a inner function or more deep.

6. Sometimes a stepping with F6 drive a system to "running" state, breaking which with "Interrupt (F9)" button display a system in non-working state on start code region. This (and 5.) say about occasionally incorrect setting of temporary breakpoint for next debugging line.

7. Context menu point "Run to Selection" or "Set PC to Selection" work incorrectly, this is continuation of problems 5.+6., noncorrect debug information or using it.

5 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    8. In Disassemble window is not enough to step one asm-command if code compiled from C: many operations "stick" to anothers for these source line and all is light-green simultaneously.

    9. In "Release" (key -o3) "volatile" variable is displayed incorrectly, although have memory region in stack and reads-writes his value continuously.

    10. If Windos-window focus set to any window, moving mouse to another and roll wheel, scrolled first window. Usually, is scrolled window under cursor !
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Optimized object code no longer aligns with lines of source code. The debug symbol values and source code line numbers represent a guess by GCC and are often not helpful. You should make sure that the code you want to single step, step return, etc is compiled without optimization. Of course this will change the order things are executed in and may change the behavior of the code. In optimized code you can sometimes single step instruction by instruction to follow what is going on.

    The compiler will also place variables in registers. This can cause the debugger to loose track. Sometimes you can look at the object code and figure out which register the variable is in. At other times, the variable will be optimized completely away and it is nowhere to be found. Welcome to software...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Yes, in -o2 and -o3 modes debugging is very difficult.

    I write code: 

    volatile int i = 0; while (!(i&1)) i += 2;

    for "hang" until I break execution and go to next line, variable "i" lay in stack, read/write in cycle and displayed incorrect, changing it to 1 in Variables window not readed in code, will be used "Set PC to Selection".

    About "Set PC to Selection": if press a left mouse button in necessary line, then press right button to call context menu in any other line an select "Set PC to Selection", code execution moves to first place line !
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    with this particular example the variable i is probably in a register, which gdb has no way of knowing. Look at the registers when that code is running. If you step one instruction at a time you should be able to deduce which register holds the variable i. Changing that register will break the loop.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    With "volatile" keyword compiler must place the variable in memory and make asm-commands for each read/write operation !

    ARMCC ignoges this rule and only writes new values to memory from registers.

    I may connect to Disassembly in any moment and try to change even if "volatile" -- GDB shall consider this.