Re: [Bochs-developers] BUG fix: ramdom breakpoint ignorance

[Forrest Y. Y. <for...@gm...>]

I see, CHECK_MAX_INSTRUCTIONS is useful when BX_DEBUGGER is defined.
However, it is incorrect by all means for CHECK_MAX_INSTRUCTIONS to return
from cpu_loop() immediately, 'coz once it returns,
BX_CPU(cpu)->guard_found.icount will be set to 0 in the next `for' loop in
bx_dbg_continue_command(), then the breakpoint will be ignored.

Here's my solution:
1. define three macros instead of one:
#if BX_SUPPORT_SMP || BX_DEBUGGER
  #define CHECK_MAX_INSTRUCTIONS_1(count) \
    int check_max_flag = 0;
  #define CHECK_MAX_INSTRUCTIONS_2(count) \
    if (check_max_flag) {                 \
      if ((count) == 0) return;           \
    }
  #define CHECK_MAX_INSTRUCTIONS_3(count) \
    if ((count) > 0) {                    \
      (count)--;                          \
      if ((count) == 0)                   \
        check_max_flag = 1;               \
    }
#else
  #define CHECK_MAX_INSTRUCTIONS_1(count)
  #define CHECK_MAX_INSTRUCTIONS_2(count)
  #define CHECK_MAX_INSTRUCTIONS_3(count)
#endif
2. add this line at the beginning of cpu_loop():
CHECK_MAX_INSTRUCTIONS_1(count);
3. add this line
CHECK_MAX_INSTRUCTIONS_2(count);
    after
#if BX_DEBUGGER || BX_EXTERNAL_DEBUGGER || BX_GDBSTUB
      if (dbg_instruction_prolog()) return;
#endif
4. replace the original CHECK_MAX_INSTRUCTIONS(count) this line
CHECK_MAX_INSTRUCTIONS_3(count);
That is, continue to run in cpu_loop() until dbg_instruction_prolog() is
called.
I've done some simple test in my computer. It seems work.

Forrest (YYu)

On Tue, Jul 29, 2008 at 2:07 PM, Stanislav Shwartsman <stl...@gm...>wrote:

>  Make sure single step or stepN commands still will be working if you
> doing this change.
>
> They are implemented exactly using this service of CHECK_MAX_INSTRUCTIONS:
>
>
>
> void bx_dbg_stepN_command(Bit32u count)
>
>                 …
>
>   for (unsigned cycle=0; !stop && cycle < count; cycle++) {
>
>     for (unsigned cpu=0; cpu < BX_SMP_PROCESSORS; cpu++) {
>
>       bx_guard.interrupt_requested = 0;
>
>       BX_CPU(cpu)->guard_found.guard_found = 0;
>
>       BX_CPU(cpu)->cpu_loop(1);
>
>
>
> If you disable it for debugger 'step' command will not stop after single
> instruction but will continue to run.
>
>
>
> Stanislav
>
>
>
> *From:* boc...@li... [mailto:
> boc...@li...] *On Behalf Of *Forrest Y.
> Yu
> *Sent:* Tuesday, July 29, 2008 8:54 AM
> *To:* boc...@li...
> *Subject:* [Bochs-developers] BUG fix: ramdom breakpoint ignorance
>
>
>
> hi all,
>
>   I use Bochs to debug my toy OS. I have found that my breakpoints are
> ignored by bochs sometimes. As a workaround, I set more than one breakpoints
> sequentially so that at lease one of them will be toggled.
>
>   Yesterday I was annoyed with this problem much, so I decided to fix it.
> Finally I found these lines in cpu.cc (bochs-2.3.5):
>
> #if BX_SUPPORT_SMP || BX_DEBUGGER
>     // The CHECK_MAX_INSTRUCTIONS macro allows cpu_loop to execute a few
>     // instructions and then return so that the other processors have a
> chance
>     // to run. This is used only when simulating multiple processors. If
> only
>     // one processor, don't waste any cycles on it!
>     CHECK_MAX_INSTRUCTIONS(max_instr_count);
> #endif
>
>   I think the `#if' line must be wrong. It should be `#if BX_SUPPORT_SMP &&
> BX_DEBUGGER' because it is expected to be true only when emulating SMP. An
> OR operator will make it true when BX_DEBUGGER is defined. When single cpu
> is emulated, the execution of `CHECK_MAX_INSTRUCTIONS(max_instr_count);'
> causes a return sometimes (when max_instr_count equals 1), which end up with
> a breakpoint being ignored.
>
>   This bug can also be found in the 20080727-snapshot. (cpu/cpu.cc::ln81)
>
>   Could anyone fix this problem? Or could I fix it and commit my
> modification? How?
>
>   Thank you in advance.
>
> Forrest (YYu)
>
> --
> Stupid is as stupid does.
>



-- 
Stupid is as stupid does.