* [ECOS] gdb vs. eCos? @ 1999-02-12 12:38 Kerry S. Kimbrough [not found] ` < 199902121646.KAA26430@cae-plus.com > 0 siblings, 1 reply; 6+ messages in thread From: Kerry S. Kimbrough @ 1999-02-12 12:38 UTC (permalink / raw) To: ecos-discuss 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> ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: < 199902121646.KAA26430@cae-plus.com >]
* Re: [ECOS] gdb vs. eCos? [not found] ` < 199902121646.KAA26430@cae-plus.com > @ 1999-02-16 15:39 ` Stan Shebs [not found] ` < 199902162112.NAA25765@andros.cygnus.com > 0 siblings, 1 reply; 6+ messages in thread From: Stan Shebs @ 1999-02-16 15:39 UTC (permalink / raw) To: kerry; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: < 199902162112.NAA25765@andros.cygnus.com >]
* Re: [ECOS] gdb vs. eCos? [not found] ` < 199902162112.NAA25765@andros.cygnus.com > @ 1999-02-17 3:21 ` Jesper Skov [not found] ` <199902171527.JAA25835@cae-plus.com> 0 siblings, 1 reply; 6+ messages in thread From: Jesper Skov @ 1999-02-17 3:21 UTC (permalink / raw) To: Stan Shebs; +Cc: kerry, ecos-discuss >>>>> "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 ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <199902171527.JAA25835@cae-plus.com>]
* Re: [ECOS] gdb vs. eCos? [not found] ` <199902171527.JAA25835@cae-plus.com> @ 1999-02-17 10:41 ` Jesper Skov 0 siblings, 0 replies; 6+ messages in thread From: Jesper Skov @ 1999-02-17 10:41 UTC (permalink / raw) To: Kerry S. Kimbrough; +Cc: ecos-discuss >>>>> "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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [ECOS] gdb vs. eCos?
@ 1999-02-21 17:55 Zubin Burjor Sethna
[not found] ` < 6006B52C37ABD211AB0900805FFE9D79169244@saturn.sg.adisys.com.au >
0 siblings, 1 reply; 6+ messages in thread
From: Zubin Burjor Sethna @ 1999-02-21 17:55 UTC (permalink / raw)
To: 'ecos discussion mailing list'
> -----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
^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: < 6006B52C37ABD211AB0900805FFE9D79169244@saturn.sg.adisys.com.au >]
* RE: [ECOS] gdb vs. eCos? [not found] ` < 6006B52C37ABD211AB0900805FFE9D79169244@saturn.sg.adisys.com.au > @ 1999-02-22 3:06 ` Jesper Skov 0 siblings, 0 replies; 6+ messages in thread From: Jesper Skov @ 1999-02-22 3:06 UTC (permalink / raw) To: Zubin Burjor Sethna; +Cc: 'ecos discussion mailing list' >>>>> "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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1999-02-22 3:06 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-02-12 12:38 [ECOS] gdb vs. eCos? Kerry S. Kimbrough [not found] ` < 199902121646.KAA26430@cae-plus.com > 1999-02-16 15:39 ` Stan Shebs [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
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).