RE: Core file support for ARM none (again)

["Fredrik Hederstierna" <fredrik dot hederstierna at verisure 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