Re: [ECOS] asynchronous break stability on i386

["Daan Huybrechs" <dhuybrechs at datax dot be>]

Hi,
I indeed fixed the problem (on my board anyway, I haven't tried the i386-pc
target).  After a breakpoint is hit, the instruction pionter points to the
memory location right after the one byte int 3 instruction.  Int 3 is then
removed and the original instruction put back, but eip is never corrected.
As it turns out, this is architecture related (whether or not the processor
corrects ip). There is even a macro in the common hal that deals with it:
HAL_STUB_PLATFORM_STUBS_FIXUP in the function handle_exception_cleanup
(hal_stub.c). So I implemented this macro to simply decrement eip.

Some remarks though:
- I didn't start looking for this kind of bug because sometimes the Ctrl-C
approach did work. It can happen if int 3 replaced another one byte
instruction that is simply skipped.
- setting a breakpoint from gdb works fine, so eip should not be decremented
then
- this could all be i386ex specific, it may not be happening on the regular
i386.

Here is what I came up with. Note that it is an ugly hack: the interrupt
code sets hal_pc_break_pc to the correct eip value. If the current eip is
exactly one bigger, I assume the breakpoint was set from the interrupt
routine, and correct it. You may not like this code:)

extern CYG_ADDRWORD hal_pc_break_pc;
#define HAL_STUB_PLATFORM_STUBS_FIXUP()    \
    if ((int) hal_pc_break_pc == get_register(PC) - 1       \
          put_register(PC, hal_pc_break_pc);                      \
    }


dh

>Daan Huybrechs wrote:
>[ breaks sometimes fail ]
>
>I had a quick check with our latest sources here, and I can confirm that
>the normal PC HAL appears to have the same symptoms. I reduced the delays
>in twothreads down to about 5 ticks on average. When I ran it, as you
>report, it sometimes ignored Ctrl-Cs. It also started randomly outputting
>"Interrupt: 39" messages occasionally as well after a while. Except it
>wasn't that random - it started when I pressed Ctrl-C so it is related.
>
>So the good news is that it's not something you've done; the bad news of
>course being that you still have the problem :-). Obviously if you do track
>it down and fix it, please tell us! At this time, we don't have anyone
>working on development of the PC HAL.
>
>> I would like to know if this is a bug in my port, or in the i386-pc
target,
>> so I have some questions:
>> - Has anyone seen this behaviour when using the regular i386-pc target?
>> - ..and possibly solved it?
>> - At first the breaks seemed to fail in code paths that include an
interrupt
>> call. Is it at all possible to break into an interrupt handler (with the
>> current code or with ecos in general)?  I recently had the same problem
in
>> rand() though, which uses no interrupt whatsoever.
>
>You can't interrupt an ISR - but any interrupt should be handled as soon as
>any running ISRs are processed - so in this case the serial interrupt
>indicating the Ctrl-C should be deferred for a very small period of time.
>
>Jifl
>--
>Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
>"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault
>