This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: Core file support for ARM none (again)
- From: "Fredrik Hederstierna" <fredrik dot hederstierna at verisure dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Mon, 1 Sep 2014 14:04:41 +0000
- Subject: RE: Core file support for ARM none (again)
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B0235320EFE07D at LEMAIL01 dot le dot imgtec dot org>,<OF771C01C5 dot 15C9D4D4-ON00257D46 dot 0041A543-00257D46 dot 0041A548 at notes dot na dot collabserv dot com>
Hello, first thanks for your feedback! :-)
>> Fredrik Hederstierna <fredrik.hederstierna@verisure.com
>> 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 systems 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 get 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 reboot),
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 etc.
> * Where to store the core file Perhaps what I'm suggesting is that the idea 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,
but maybe its a chicken-egg problem, I guess it wont go into the FreeRTOS repo
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 some thoughts)
> Regards, Matthew
Thanks for you good and interesting thoughts!
BR Fredrik