[ECOS] gdb vs. eCos?

[ECOS] gdb vs. eCos?

[Kerry S. Kimbrough]

I could find no info on this topic in the FAQ or other info at
www.cygnus.com/ecos, etc. But I expect this is an easy question for someone
on this list.

The question: what's the story on integration of gdb with eCos? I assume
that there exists a version of gdb that is "eCos-aware", but am I right? If
so, can someone point me to details like gdb version, command documentation,
etc.? By "eCos-aware", of course, I mean a gdb that can view RTOS info
(e.g. task status, task priorities), that can set breakpoints conditioned on
task info (e.g. break in task X only), that can debug interrupt handlers,
etc.

-- 


Regards,

Kerry Kimbrough   <kerry@cae-plus.com>

Re: [ECOS] gdb vs. eCos?

[Stan Shebs]

   Date: Fri, 12 Feb 1999 10:46:08 -0600
   From: "Kerry S. Kimbrough" <kerry@cae-plus.com>

(Hi Kerry!)

   I could find no info on this topic in the FAQ or other info at
   www.cygnus.com/ecos, etc. But I expect this is an easy question for someone
   on this list.

   The question: what's the story on integration of gdb with eCos? I assume
   that there exists a version of gdb that is "eCos-aware", but am I right? If
   so, can someone point me to details like gdb version, command documentation,
   etc.? By "eCos-aware", of course, I mean a gdb that can view RTOS info
   (e.g. task status, task priorities), that can set breakpoints conditioned on
   task info (e.g. break in task X only), that can debug interrupt handlers,
   etc.

eCos support in GDB consists of a couple extensions so far.  The first
is to display additional information about eCos threads, such as
priority.  Both this and basic thread control are integrated into
GDB's basic thread support, which is documented in the GDB manual.
GDB's thread support does allow per-thread breakpoints and such, so
most of what people want is there already, the main work for eCos was
to make it understand GDB's standard protocol for all this.  The
Insight (gdbtk) GUI for GDB includes a thread window as well.

The second is a much more experimental change to better control
stepping of threads by locking out the scheduler.  Right now, when you
step, you unleash the scheduler, which can have some pretty
counterintuitive side effects.  So we've defined a new GDB variable
`scheduler-locking' that you can set as desired, either letting all
threads run, or just the one that you're stepping.  Again, this is
still experimental (Michael Snyder will hate me even for mentioning
it!).

We haven't done anything about interrupt handler debugging.  My
understanding is that eCos might need some additional tweaking for
that.  (True eCos'ers jump in here please.)  GDB doesn't really care -
if the OS hands it a valid state, it will try to make sense of it,
whether it's in the main code or in an interrupt handler.

There are a couple other ideas in the works, but they're not far
enough to talk about yet.  We are interested in getting additional
suggestions too!

Oh yeah, the GDB tweaks above are post-4.17.  The thread support you
can find in the eCos sourceware release, the scheduler locking in
current GDB snapshots.  Both will be in 4.18, which is going to be
coming out soon.

							Stan

Re: [ECOS] gdb vs. eCos?

[Jesper Skov]

>>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:
Stan> We haven't done anything about interrupt handler debugging.  My
Stan> understanding is that eCos might need some additional tweaking
Stan> for that.  (True eCos'ers jump in here please.)  GDB doesn't
Stan> really care - if the OS hands it a valid state, it will try to
Stan> make sense of it, whether it's in the main code or in an
Stan> interrupt handler.

If the trap exception vector is different from the interrupt vector
you want to debug, it can be done if you are careful; i.e., set your
breakpoint after the pre-exception state has been saved.

Also, using a simulator for debugging the interrupt handlers can be a
great help since it doesn't trash so much state as the gdb stub does
(that is, debugging in a SIM is truly transparent for the program
being run -- at least I haven't had any problems).

I've stepped my way through the PowerPC interrupt handler more than
once using GDB (although I prefer the SIM way -- it's faster).

Jesper

Re: [ECOS] gdb vs. eCos?

[Jesper Skov]

>>>>> "Kerry" == Kerry S Kimbrough <kerry@cae-plus.com> writes:

>> Also, using a simulator for debugging the interrupt handlers can be
>> a great help since it doesn't trash so much state as the gdb stub
>> does (that is, debugging in a SIM is truly transparent for the
>> program being run -- at least I haven't had any problems).

Kerry> Interesting comment, Jesper. Can you explain a bit more?

Kerry> Are you describing a SIM(ulator) that provides a debugging
Kerry> capability independent and different from gdb? If so, are you
Kerry> referring to a specific SIM? Can you describe a bit more about
Kerry> what it does? What is the "SIM way"?  Does the SIM run together
Kerry> with gdb, or are they mutually exclusive? What is the
Kerry> relationship between the SIM and the gdb stub?

Sorry, my description may have been a bit vague. I'll try a bit
harder:

When using GDB to debug software on a target board, you rely on the
GDB stub on the board to communicate information back to GDB on the
host computer. 

Given that the stub runs on the target, there are some limitations
imposed on it; for example, you cannot put breakpoints or single step
through the trap vector code, since the GDB stub is using this
exception vector to manage the breakpoints in the first place.

By the same token, you cannot put a breakpoint at the start of an
interrupt vector because CPU state will be lost when it is hit;
specifically for the PowerPC, the contents of SSR0 and SSR1 has not
yet been saved by the interrupt vector code. When the breakpoint is
hit, the contents of SRR0 and SRR1 is overwritten, losing all
information about the CPU's state prior to the (original) interrupt.
(got all that? :)



When you are using the simulator instead, no GDB stub is required. All
of GDB's interaction with the "target" happens through magic hooks in
the simulator (I think). This means that (in theory anyway) no state
should ever be lost due to conflicts between GDB stub code and the
application code. This in turn allows you to debug interrupt and
exception vectors without problems.

When you build the eCos tools, the simulator is built as a library
that is used both by a standalone program (powerpc-eabi-run) and by
GDB (I think). There are some examples in the documentation of how to
connect to the simulator from GDB.

Cheers,
Jesper

RE: [ECOS] gdb vs. eCos?

[Jesper Skov]

>>>>> "Zubin" == Zubin Burjor Sethna <sethnaz@sg.adisys.com.au> writes:

Zubin> 	[Zubin Burjor Sethna] Is it possible to resume normal
Zubin> execution after GDB has stopped at a breakpoint in an interrupt
Zubin> handler, on the actual target (not the simulator)? I've read
Zubin> that you cannot execute the RFI (Return From Interrupt) after
Zubin> breaking in an interrupt handler.

If the breakpoint is set at a place where it doesn't trash any CPU
state, it should be possible. 

If you set the breakpoint in code that is storing/restoring CPU state
it will fail, but if you set a breakpoint "in the middle" of an
interrupt handler it should be OK.

Jesper

RE: [ECOS] gdb vs. eCos?

[Zubin Burjor Sethna]

> -----Original Message-----
> From:	Jesper Skov [SMTP:jskov@cygnus.co.uk]
> Sent:	Wednesday, February 17, 1999 6:22 PM
> To:	Stan Shebs
> Cc:	kerry@cae-plus.com; ecos-discuss@cygnus.com
> Subject:	Re: [ECOS] gdb vs. eCos?
> 
> 
> Also, using a simulator for debugging the interrupt handlers can be a
> great help since it doesn't trash so much state as the gdb stub does
> (that is, debugging in a SIM is truly transparent for the program
> being run -- at least I haven't had any problems).
> 
> I've stepped my way through the PowerPC interrupt handler more than
> once using GDB (although I prefer the SIM way -- it's faster).
> 
> Jesper
> 
> 
	[Zubin Burjor Sethna]  Is it possible to resume normal execution
after GDB has stopped at a breakpoint in an interrupt handler, on the actual
target (not the simulator)? I've read that you cannot execute the RFI
(Return From Interrupt) after breaking in an interrupt handler.

	Zubin