This is the mail archive of the
mailing list for the eCos project.
Re: RedBoot+GDB+application combo question
- From: Savin Zlobec <savin dot zlobec at email dot si>
- To: eisvogsn at iis dot fhg dot de
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Fri, 20 Feb 2004 20:02:14 +0100
- Subject: [ECOS] Re: RedBoot+GDB+application combo question
> Hi list,
> I've built a working RedBoot loader w/ GDB on a V850E/MS1 system with
> software breakpoints ( "br *" ) and an unused timer output that is fed
> back into the NMI for periodic "bp hit" checking i.e. much like the
> existing V850 port, just heavily tweaked for V850E/MS1.
Is there any reason why 'dbtrap' instruction can't be used for breakpoints ?
> Now I'm into running the kernel test suite and the question I haven't
> seen answered is, how do I go about the GDB stuff. I have RedBoot in
> internal flash and load the application into RAM. Do I keep the GDB code
> in RedBoot and leave out GDB completely for the application, therefore
> debugging by using RedBoot's GDB, or should I pack GDB into the app and
> make it override RedBoot's VSR table, with RedBoot completely out of the
> picture once I've typed "go"?
> If there's more than one way, I'd like the "elegant" route. ;)
Do you have any thoughts against putting GDB stubs into RedBoot ?
If you start the timer which you use for breakpoint support at RedBoot
startup it will of course bring some overhead also if you don't do any
debugging - this can be avoided by starting it the first time breakpoint()
is called (i.e. starting GDB stubs).
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss