* [ECOS] does ecos support generating core files or kernel crash dumps? @ 2003-10-15 17:29 Adrian Caceres 2003-10-15 18:08 ` Gary Thomas 0 siblings, 1 reply; 4+ messages in thread From: Adrian Caceres @ 2003-10-15 17:29 UTC (permalink / raw) To: ecos-discuss I am wondering if ecos already supports generating core files or crash dumps for post-mortem analysis using gdb. thanks adrian -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] does ecos support generating core files or kernel crash dumps? 2003-10-15 17:29 [ECOS] does ecos support generating core files or kernel crash dumps? Adrian Caceres @ 2003-10-15 18:08 ` Gary Thomas 2003-10-15 20:37 ` Adrian Caceres 0 siblings, 1 reply; 4+ messages in thread From: Gary Thomas @ 2003-10-15 18:08 UTC (permalink / raw) To: Adrian Caceres; +Cc: ecos-discuss On Wed, 2003-10-15 at 11:28, Adrian Caceres wrote: > I am wondering if ecos already supports generating core files or crash > dumps for post-mortem analysis using gdb. No. Where would you put them [in an embedded system]? If the application "crashes", just connect to it using GDB and figure out why. -- Gary Thomas <gary@mlbassoc.com> MLB Associates -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] does ecos support generating core files or kernel crash dumps? 2003-10-15 18:08 ` Gary Thomas @ 2003-10-15 20:37 ` Adrian Caceres 2003-10-15 20:43 ` Gary Thomas 0 siblings, 1 reply; 4+ messages in thread From: Adrian Caceres @ 2003-10-15 20:37 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-discuss Many embedded systems have a local/ide type bus to a flash. Assuming the basic driver to such interface was not affected by the crash, it would be possible to write a dump to it. Or there might be some storage available across some network interface. The embedded system could send the crash dump over to the other end for storage. Having gdb support is great for development, but when it comes to beta, a core dump can be more useful. It is not rare for a specific problem to only occur at some beta site and there is simply no way to gdb to it. The serial port might not even be stuffed or accesible in these units. But give them a unit with an extra large flash, wait for the problem to happen again, get the unit back, and now you might have all the information you need. If the embedded device already has a removable flash such as a digital or video camera, the process is simply a swap of a flash. - adrian Gary Thomas wrote: >On Wed, 2003-10-15 at 11:28, Adrian Caceres wrote: > > >>I am wondering if ecos already supports generating core files or crash >>dumps for post-mortem analysis using gdb. >> >> > >No. Where would you put them [in an embedded system]? > >If the application "crashes", just connect to it using GDB >and figure out why. > > > -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] does ecos support generating core files or kernel crash dumps? 2003-10-15 20:37 ` Adrian Caceres @ 2003-10-15 20:43 ` Gary Thomas 0 siblings, 0 replies; 4+ messages in thread From: Gary Thomas @ 2003-10-15 20:43 UTC (permalink / raw) To: Adrian Caceres; +Cc: ecos-discuss On Wed, 2003-10-15 at 14:37, Adrian Caceres wrote: > Many embedded systems have a local/ide type bus > to a flash. Assuming the basic driver to such interface was not affected > by the crash, it would be possible to write a dump to it. > Or there might be some storage available across some network > interface. The embedded system > could send the crash dump over to the other end for storage. > > Having gdb support is great for development, but when it comes > to beta, a core dump can be more useful. It is not rare for > a specific problem to only occur at some beta site and there > is simply no way to gdb to it. The serial port might not even > be stuffed or accesible in these units. But give them a unit > with an extra large flash, wait for the problem to happen again, > get the unit back, and now you might have all the information you need. > If the embedded device already has a removable flash such > as a digital or video camera, the process is simply a swap of > a flash. > These are wonderful arguments (I made the same ones more than 25 years ago to my boss at the time...). The infrastructure is all there for you to add such a capability, it's just not something that has ever been done before. As for your first statement about having a local IDE bus with FLASH - that's probably less than 2% of all of the systems that eCos is normally deployed on, but if you've got it, flaunt it! > - adrian > > Gary Thomas wrote: > > >On Wed, 2003-10-15 at 11:28, Adrian Caceres wrote: > > > > > >>I am wondering if ecos already supports generating core files or crash > >>dumps for post-mortem analysis using gdb. > >> > >> > > > >No. Where would you put them [in an embedded system]? > > > >If the application "crashes", just connect to it using GDB > >and figure out why. > > > > > > -- Gary Thomas <gary@mlbassoc.com> MLB Associates -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-10-15 20:43 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-10-15 17:29 [ECOS] does ecos support generating core files or kernel crash dumps? Adrian Caceres 2003-10-15 18:08 ` Gary Thomas 2003-10-15 20:37 ` Adrian Caceres 2003-10-15 20:43 ` Gary Thomas
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).