From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3443 invoked by alias); 16 Oct 2003 07:27:20 -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 3435 invoked from network); 16 Oct 2003 07:27:18 -0000 Received: from unknown (HELO mail.frequentis.com) (213.47.210.148) by sources.redhat.com with SMTP; 16 Oct 2003 07:27:18 -0000 Received: from FRQVIE-EXT-MTA by mail.frequentis.com with Novell_GroupWise; Thu, 16 Oct 2003 09:27:16 +0200 Message-Id: Date: Thu, 16 Oct 2003 07:27:00 -0000 From: "Reinhard JESSICH" To: , Cc: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Re: [ECOS] does ecos support generating core files or kernel crashdumps? X-SW-Source: 2003-10/txt/msg00284.txt.bz2 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 t= hread and if this is not possible a stackdump of the interrupt stack. The stackdu= mp is not a simple memory dump, but the context of each called function. This all= owes 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 er= ased 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. Th= is would be a real core feature. If it is too big for the unused memory, we can stor= e it on a flash. We have submitted a patch for our process extension, but EcosCentric does n= ot accept it. If you are interrested, search in the archives for memory protec= tion. 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 --=20 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 -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss