From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4105 invoked by alias); 16 Oct 2003 11:54:44 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 4097 invoked from network); 16 Oct 2003 11:54:43 -0000 Received: from unknown (HELO hermes.chez-thomas.org) (63.225.98.241) by sources.redhat.com with SMTP; 16 Oct 2003 11:54:43 -0000 Received: by hermes.chez-thomas.org (Postfix, from userid 2000) id 296CD50E0FC; Thu, 16 Oct 2003 05:54:43 -0600 (MDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by hermes.chez-thomas.org (Postfix) with ESMTP id 25B1B50E0FB; Thu, 16 Oct 2003 05:54:42 -0600 (MDT) From: Gary Thomas To: Reinhard JESSICH Cc: adrian@atheros.com, ecos-discuss@sources.redhat.com In-Reply-To: References: Content-Type: text/plain Organization: MLB Associates Message-Id: <1066305281.32461.112.camel@hermes> Mime-Version: 1.0 Date: Thu, 16 Oct 2003 11:54:00 -0000 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: Re: [ECOS] does ecos support generating core files or kernel crashdumps? X-SW-Source: 2003-10/txt/msg00299.txt.bz2 On Thu, 2003-10-16 at 01:27, Reinhard JESSICH wrote: > Hello > > We had similar needs for our development. > As you know we have implemented a process model and memory protection > for the PowerPC. We also implemented the first step of a core dump feature. > > If an exception occures (dived by zero, illegal read/write, assert, ... ), we write > the exception text, the thread, the registers, a stackdump of the running thread > and if this is not possible a stackdump of the interrupt stack. The stackdump is > not a simple memory dump, but the context of each called function. This allowes > us to see the call graph and the exact position where the exception occures very > easily. We write the whole information to an unused memory, which is not erased > during reset. We can store as much core dumps as memory is available. > After reset we can read the core's via telnet or serail line. > > We plan to store the complete context of the thread and its memory in > compressed form. This allowes us to see the content of variables in gdb. This would > be a real core feature. If it is too big for the unused memory, we can store it on a > flash. > > We have submitted a patch for our process extension, but EcosCentric does not Just a fine point - eCosCentric [itself] has nothing to do with this decision. These choices are made by the eCos maintainers, who themselves [hopefully] represent the eCos community as a whole. > accept it. If you are interrested, search in the archives for memory protection. > The patch was submitted by my colleague Thomas Binder. > You will find the core code there. In the meantime we have continued the > development, but this parts should be still the same. > > Best regards, > Reinhard > > > -- > Ing. Reinhard Jessich Phone: +43/1/81150/2395 > Software Design Fax: +43/1/81150/3169 > Frequentis Nachrichtentechnik GmbH A-1120 Wien, Spittelbreitengasse 34 > http://www.frequentis.com eMail: reinhard.jessich@frequentis.com -- Gary Thomas 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