[ECOS] Difference between CTRLC & BREAK support on GDB stubs
Wed Oct 18 01:29:00 GMT 2000
>>>>> "Rosimildo" == Rosimildo daSilva <email@example.com> writes:
Rosimildo> The macro is not defined
It should be set in the eCos configuration, not as part of your
Rosimildo> I have not made myself clear before, so let me try again:
Rosimildo> + I have a "GDB stub" that works, except the "Ctrl-c"
Rosimildo> feature. A can set breakpoints, step, etc. Whenever a hit
Rosimildo> "Ctrl-C", the stub stops as expected( see below ). The
Rosimildo> problem is that from then on, every step hits a "break"
Rosimildo> instruction. In another works, I cannot "cont" the
Rosimildo> executation of the application.
Well, it seems that the problem is that you do not have stubs in
ROM. Look at the code here:
void cyg_hal_user_break( CYG_ADDRWORD *regs )
// The following code should be at the very start of this function so
// that it can access the RA register before it is saved and reused.
register CYG_WORD32 ra;
asm volatile ( "move %0,$31;" : "=r" (ra) );
typedef void install_bpt_fn(void *epc);
HAL_SavedRegisters *sreg = (HAL_SavedRegisters *)regs;
install_bpt_fn *ibp = (install_bpt_fn *)hal_vsr_table;
if( regs == NULL ) pc = ra;
else pc = sreg->pc;
if( ibp != NULL ) ibp((void *)pc);
extern void breakpoint(void);
It uses the hal_vsr_table to find the address of a function (in ROM!)
that will set the breakpoint. If you don't have a stub in ROM, that
will obviously not work.
The first alternative is to include stubs in the application image by
enabling CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS. In that case the stub
code will realize that the break instruction in breakpoint() was hit,
and will increment the address when continuing.
The second alternative is just putting a breakpoint in the code. It's
a dead end. And that seems to be what you are hitting.
So (a) your environment is incomplete, or (b) your configuration is
More information about the Ecos-discuss