[ECOS] Strange step behaviour

[ECOS] Strange step behaviour

[Fabrice Gautier]

Hi,

I recently have done some modifications to the gdb stub used in eCos for the
i386 target.
Now it works almost fine except this:

When I step in the C source with "next", if there is a 'call' instruction in
the set of asm instruction generated by the C source line, I caught a
sigtrap with the pc set just after the call instruction. So when there is no
call instruction generated by the C source everything is as usual but if
there is some function calls I will get as many SIGTRAP than there are
calls. For example a "i=i+1" line will not trigger a signal and one "next"
will pass the line, but something like "str=(char *)malloc(strlen(s))" will
take 3 next to execute.  If I try to "step" instead of "next" then i will
have a SIGTRAP on the first line of the function I'm going into, and then if
I do a "finnish" I will get another SIGTRAP on the instruction after the
call.

I'm using insight and the mixed C-asm mode made it very easy to see what's
happening. And when I say i get a SIGTRAP i mean that there is a SIGTRAP
dialog box that appear but i guess the equivalent in the command line gdb
will be a SIGTRAP message that shouldn't appear.

I can still debug, but the problem is  a bit irritating...

I'm wondering what can cause the problem, what does the stub do when
'next'ing. 
The main change I've done in the eCos gdb stub was to allow the program to
be interrupted with a CTRL-C and maybe in the process I've changed something
wrong but I can't see what. If you can enlight me on the way the stub
process the debug trap, how the "next" and "step" are done, what kind of
breakpoints are used for this operations, does it use some hardware debug
capabilities or only "int $3" instructions, how does gdb manage the
difference between user breakpoint and breakpoint used for stepping, does
the stub put a breakpoint after each "call" instruction and why ?

Thanks

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com