[ECOS] GDB Ctrl-C problem

[ECOS] GDB Ctrl-C problem

[Xavier Wang]

Hi,

I'm porting eCos to a MIPS architecture from TX39/JMR3904
template. My problem is that when I press Ctrl-C in GDB,
the program stops at breakpoint() (in hal_stub.c) which contains
only one instruction: HAL_BREAKPOINT(_breakinst). How
could I let the GDB stop exactly at the interrupted instruction
rather than the breakpoint instruction itself? By looking into
cyg_hal_user_break(), it seems that it might help if
CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS is defined,
since in that case it will call breakpoint() instead of calling
HAL_BREAKPOINT() directly, and it seems that breakpoint()
should handle the program counter stuff. But in fact the breakpoint()
contains only one instruction HAL_BREAKPOINT(), so it makes
no difference. Could cyg_hal_gdb_interrupt() help? Can I replace
breakpoint() with cyg_hal_gdb_interrupt() in cyg_hal_user_break()?

The following is my configurations:

- eCos v1.3.1
- GDB stubs
      GDB Ctrl-C support enabled
      GDB break support disabled
      Startup type = ROM
      loaded and run by ICE
- application
      GDB stubs included
      GDB Ctrl-C support enabled
      GDB break support disabled
      Work with a ROM Monitor = GDB stubs
      Startup type = RAM

Thank you.

Re: [ECOS] GDB Ctrl-C problem

[Jonathan Larmour]

Xavier Wang wrote:
> 
> Hi,
> 
> I'm porting eCos to a MIPS architecture from TX39/JMR3904
> template. My problem is that when I press Ctrl-C in GDB,
> the program stops at breakpoint() (in hal_stub.c) which contains
> only one instruction: HAL_BREAKPOINT(_breakinst). How
> could I let the GDB stop exactly at the interrupted instruction
> rather than the breakpoint instruction itself? By looking into
> cyg_hal_user_break(), it seems that it might help if
> CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS is defined,
> since in that case it will call breakpoint() instead of calling
> HAL_BREAKPOINT() directly, and it seems that breakpoint()
> should handle the program counter stuff. But in fact the breakpoint()
> contains only one instruction HAL_BREAKPOINT(), so it makes
> no difference. Could cyg_hal_gdb_interrupt() help? Can I replace
> breakpoint() with cyg_hal_gdb_interrupt() in cyg_hal_user_break()?
> 
> The following is my configurations:
> 
> - eCos v1.3.1
> - GDB stubs
>       GDB Ctrl-C support enabled
>       GDB break support disabled
>       Startup type = ROM
>       loaded and run by ICE
> - application
>       GDB stubs included
>       GDB Ctrl-C support enabled
>       GDB break support disabled
>       Work with a ROM Monitor = GDB stubs
>       Startup type = RAM

This isn't right -if you are including stubs, you should have break support
enabled and ctrl-c support disabled in your application.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] GDB Ctrl-C problem

[Xavier Wang]

> > 
> > Hi,
> > 
> > I'm porting eCos to a MIPS architecture from TX39/JMR3904
> > template. My problem is that when I press Ctrl-C in GDB,
> > the program stops at breakpoint() (in hal_stub.c) which contains
> > only one instruction: HAL_BREAKPOINT(_breakinst). How
> > could I let the GDB stop exactly at the interrupted instruction
> > rather than the breakpoint instruction itself? By looking into
> > cyg_hal_user_break(), it seems that it might help if
> > CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS is defined,
> > since in that case it will call breakpoint() instead of calling
> > HAL_BREAKPOINT() directly, and it seems that breakpoint()
> > should handle the program counter stuff. But in fact the breakpoint()
> > contains only one instruction HAL_BREAKPOINT(), so it makes
> > no difference. Could cyg_hal_gdb_interrupt() help? Can I replace
> > breakpoint() with cyg_hal_gdb_interrupt() in cyg_hal_user_break()?
> > 
> > The following is my configurations:
> > 
> > - eCos v1.3.1
> > - GDB stubs
> >       GDB Ctrl-C support enabled
> >       GDB break support disabled
> >       Startup type = ROM
> >       loaded and run by ICE
> > - application
> >       GDB stubs included
> >       GDB Ctrl-C support enabled
> >       GDB break support disabled
> >       Work with a ROM Monitor = GDB stubs
> >       Startup type = RAM
> 
> This isn't right -if you are including stubs, you should have break support
> enabled and ctrl-c support disabled in your application.
> 
> Jifl
> -- 
> Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
> Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
> 

Thanks, Jifl.

I'd changed the configuration of my application to have break support enabled and
Ctrl-C support disabled but still got the same result, ie, GDB stopped at
HAL_BREAKPOINT() in breakpoint().

Any suggestion?
Thanks.

Re: [ECOS] GDB Ctrl-C problem

[Jonathan Larmour]

Xavier Wang wrote:
> 
> I'd changed the configuration of my application to have break support enabled and
> Ctrl-C support disabled but still got the same result, ie, GDB stopped at
> HAL_BREAKPOINT() in breakpoint().

Okay, I just answered with the most obvious thing. But at a guess you could
try editting hal/mips/jmr3904/VERSION/src/plf_misc.c and editting
cyg_hal_user_break and replacing

#if defined(CYGSEM_HAL_USE_ROM_MONITOR_CygMon)
 
with

#if (defined(CYGSEM_HAL_USE_ROM_MONITOR_CygMon) || \  
  defined(CYGSEM_HAL_USE_ROM_MONITOR_GDB_stubs))

But I haven't tried this so I'm only guessing.

The alternative is using anonymous CVS, but that may be a bit of a system
shock as there are many changes.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] GDB Ctrl-C problem

[Xavier Wang]

> Xavier Wang wrote:
> > 
> > I'd changed the configuration of my application to have break support enabled and
> > Ctrl-C support disabled but still got the same result, ie, GDB stopped at
> > HAL_BREAKPOINT() in breakpoint().
> 
> Okay, I just answered with the most obvious thing. But at a guess you could
> try editting hal/mips/jmr3904/VERSION/src/plf_misc.c and editting
> cyg_hal_user_break and replacing
> 
> #if defined(CYGSEM_HAL_USE_ROM_MONITOR_CygMon)
>  
> with
> 
> #if (defined(CYGSEM_HAL_USE_ROM_MONITOR_CygMon) || \  
>   defined(CYGSEM_HAL_USE_ROM_MONITOR_GDB_stubs))
> 
> But I haven't tried this so I'm only guessing.
> 
> The alternative is using anonymous CVS, but that may be a bit of a system
> shock as there are many changes.
> 
> Jifl

Jifl, thanks.

I tried the above but found that the *ibp* pointer is null, so cyg_hal_user_break() did
nothing and returned. Any more suggestion?

I'm seriously considering using anonymous CVS, but I wonder whether it's easy or
not to port from current v1.3.1 to anon CVS. Furthermore, since anon CVS is still
being upgraded rapidly, I'm afraid that the porting is endless.

Thanks again.