public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Stan Shebs <shebs@cygnus.com>
To: kerry@cae-plus.com
Cc: ecos-discuss@cygnus.com
Subject: Re: [ECOS] gdb vs. eCos?
Date: Tue, 16 Feb 1999 15:39:00 -0000	[thread overview]
Message-ID: <199902162112.NAA25765@andros.cygnus.com> (raw)
In-Reply-To: < 199902121646.KAA26430@cae-plus.com > (kerry@cae-plus.com)

   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


  parent reply	other threads:[~1999-02-16 15:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-02-12 12:38 Kerry S. Kimbrough
     [not found] ` < 199902121646.KAA26430@cae-plus.com >
1999-02-16 15:39   ` Stan Shebs [this message]
     [not found]     ` < 199902162112.NAA25765@andros.cygnus.com >
1999-02-17  3:21       ` Jesper Skov
     [not found]         ` <199902171527.JAA25835@cae-plus.com>
1999-02-17 10:41           ` Jesper Skov
1999-02-21 17:55 Zubin Burjor Sethna
     [not found] ` < 6006B52C37ABD211AB0900805FFE9D79169244@saturn.sg.adisys.com.au >
1999-02-22  3:06   ` Jesper Skov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199902162112.NAA25765@andros.cygnus.com \
    --to=shebs@cygnus.com \
    --cc=ecos-discuss@cygnus.com \
    --cc=kerry@cae-plus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).