Re: [ECOS] Difference between CTRLC & BREAK support on GDB stubs

[Jesper Skov <jskov at redhat dot com>]

>>>>> "Rosimildo" == Rosimildo daSilva <rosimildo@hotmail.com> writes:

Rosimildo> The macro is not defined
Rosimildo> CYGSEM_HAL_USE_ROM_MONITOR_GDB_stubs.

It should be set in the eCos configuration, not as part of your
application code.

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 )
{
#if defined(CYGSEM_HAL_USE_ROM_MONITOR_CygMon)
    // 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);
            CYG_WORD32 pc;
            HAL_SavedRegisters *sreg = (HAL_SavedRegisters *)regs;
            install_bpt_fn *ibp = (install_bpt_fn *)hal_vsr_table[35];

            if( regs == NULL ) pc = ra;
            else pc = sreg->pc;

            if( ibp != NULL ) ibp((void *)pc);
        }
    
#elif defined(CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS)

        {
            extern void breakpoint(void);
            breakpoint();
        }
    
#else

        HAL_BREAKPOINT(breakinst);

#endif
}

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
bad.

Jesper