[ECOS] RE: Strange step behaviour

Fabrice Gautier Fabrice_Gautier@sdesigns.com
Tue Oct 31 11:55:00 GMT 2000


Hi,

Well, after some observations, I've narrowed the problem.

First, I think I saw the way of gdb: When doing a next or a step and if
there is no function call, gdb send to the stub as many 's' (step) packet as
needed to execute the whole line. But when the asm instruction is a 'call'
gdb put a breakpoint (either at the beggining of the called function  for a
step, or on  the instruction after the 'call' for a next) and then it send a
'c' (continue) packet to the stub.

Now we also see that a single 'step' is handled by the hardware. A flag in
the flag register (aka eflags, aka PS) is set so that after each instruction
an Int1 is fired. But when setting a breakpoint its Int3 which is triggered.
So the difference: GDB signal the Int3 as a SIGTRAP, but Int1 is handled in
other ways. 

So now why does this worked almost fine before, and now it does also work
almost fine but not the same almost?

Well, One thing that occurred with the previous eCos stub (which i believe
was not very different than the classic gdb stub) is that when I hitted
Ctrl-C, the program was interrupted but the PC was always one byte too far
so that when you wanted to Continue the program crashed (set $eip=$eip-1 was
a quick workaround) . The explanation seemed to be that when you hit a
breakpoint, the PC points to the instruction following the int3 instruction
but -as I've read in some comments inside the stub code- it should point to
the int 3 instruction. And  now with the adaptation of the stub to work with
Redboot, in order to make the Ctrl-C works correctly this thing has to be
corrected. And so in the 'cleanup' a FIXUP macro rewinded the PC of 1 byte
when we had an int3.

But know I guess that gdb itself expect the PC to be a byte farther, and
when it receive the T packet from the stub I guess it does not find the PC
where it should be after hitting the breakpoint placed by itself. So it
think this in an user breakpoint and not a temporary breakpoint used for
internals purposes. 

As I see it know it seems that I should have to adjust the PC if and only if
the breakpoint is the consequence of Ctrl-C

Any thoughts about this?

Thanks

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 
 



> -----Original Message-----
> From: Fabrice Gautier [ mailto:Fabrice_Gautier@sdesigns.com ]
> Sent: Monday, October 30, 2000 3:09 PM
> To: GDB (E-mail)
> Cc: Ecos-List (E-mail)
> Subject: Strange step behaviour
> 
> 
> 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 
> 


More information about the Ecos-discuss mailing list