From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21254 invoked by alias); 1 Sep 2014 14:05:03 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 21202 invoked by uid 89); 1 Sep 2014 14:05:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail.securitas-direct.com Received: from mail.securitas-direct.com (HELO mail.securitas-direct.com) (91.199.64.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Mon, 01 Sep 2014 14:04:49 +0000 Received: from smtp.notes.lotuslive.com (HELO smtp.notes.na.collabserv.com) ([170.225.217.95]) by mail.securitas-direct.com with ESMTP; 01 Sep 2014 16:04:46 +0200 Received: from /spool/local by smtp.notes.na.collabserv.com with ESMTP server ready for from ; Mon, 1 Sep 2014 14:04:45 -0000 Received: from usdl3-ln00-ap06.ben.dc5.lotusliveops.com (10.15.34.24) by smtp.notes.na.collabserv.com (10.14.54.17) with ESMTP server ready; Mon, 1 Sep 2014 14:04:42 -0000 Received: from usdl3-ln00-ap41.ben.dc5.lotusliveops.com ([10.16.34.59]) by usdl3-ln00-ap06.ben.dc5.lotusliveops.com with ESMTP id 2014090114044171-96859 ; Mon, 1 Sep 2014 14:04:41 +0000 In-Reply-To: <6D39441BF12EF246A7ABCE6654B0235320EFE07D@LEMAIL01.le.imgtec.org> Subject: RE: Core file support for ARM none (again) From: "Fredrik Hederstierna" To: Matthew Fortune Cc: "gdb@sourceware.org" Date: Mon, 01 Sep 2014 14:05:00 -0000 MIME-Version: 1.0 References: <6D39441BF12EF246A7ABCE6654B0235320EFE07D@LEMAIL01.le.imgtec.org>, X-LLNOutbound: False X-Disclaimed: 28947 X-TNEFEvaluated: 1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 x-cbid: 14090114-3893-0000-0000-000007BE1160 X-IBM-ISS-SpamDetectors: Score=0; BY=0; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0; ST=0; TS=0; UL=0; ISC= X-IBM-ISS-DetailInfo: BY=3.00002944; HX=3.00000228; KW=3.00000007; PH=3.00000003; SC=3.00000036; SDB=6.00409268; UDB=6.00148660; UTC=2014-09-01 14:04:43 x-cbparentid: 14090114-3894-0000-0000-000006F05A35 Message-Id: X-SW-Source: 2014-09/txt/msg00005.txt.bz2 Hello, first thanks for your feedback! :-) >> Fredrik Hederstierna > I just post these lines again, since its slightly frustrating to not >> get any response nor feedback at all. > Is it just me thinking that >> having core file support also for non-Linux > ARM EABI targets would >> be great? Any feedback is most welcome, good or bad! > While I don't have any particular need to work with bare metal ARM system= s the > general concept seems relatively useful for RTOS or no-OS developers. > There is the question of how helpful this is in the general case as > the proposal requires custom client side support. I.e. A user would > have to deal with at least these three problems for the GDB support > to be useful. > * The scenarios where the target has failed in some way but is still > capable of executing code. Yes, in our target system we normally eg. disable all IRQ-handlers if we ge= t faults or exceptions, before we generate our core files for our ARM926E core. But for eg. cortex there are maybe non maskable interrupts. Though the core file mirror the state of the system at that specific time, so I think GDB could support it, then if its not possible for any specific client system to provide the core, still it will gain alot of other systems. > * Implementations of the target side stub in something like freertos or > semi-hosting style code. Yes, we could absolutely provide you with an example implementation, though I was not sure where to place this client piece of code, since its not really GDB code, rather client stubs. Our code generate core files using flash-store interface, to store the generated file to a flash secondary storage, to later (normally after reboo= t), be able to read and send up to server as a post-mortem blob that host sw can automatically parse and generate user-friendly reports, eg webb-pages containing, number of crashes, type of crashes, most frequent crashes etc e= tc. > * Where to store the core file Perhaps what I'm suggesting is that the i= dea may need an example target side > implementation in some free software to gain interest. Yes maybe you are right, we could try provide eg. FreeRTOS example code,=20 but maybe its a chicken-egg problem, I guess it wont go into the FreeRTOS r= epo if the GDB stuff is not in place already... > (I have no say in what is and is not suitable for GDB, these are just som= e thoughts) > Regards, Matthew=20 Thanks for you good and interesting thoughts! BR Fredrik