Core file support for ARM none (again)

Core file support for ARM none (again)

[Fredrik Hederstierna]

Hi

Several times during the last years I've been trying to push to get some kind of core file support for GDB bare-metal targets.

posts:

https://www.sourceware.org/ml/gdb/2012-04/msg00073.html
https://www.sourceware.org/ml/gdb/2012-06/msg00022.html
https://www.sourceware.org/ml/gdb/2013-06/msg00053.html

Though I've hardly got any feedback at all.

I've even created an issue, and implemented a proposed solution with patch:

https://sourceware.org/bugzilla/show_bug.cgi?id=14383

We use this today at our company to receive core files from customer sites in real production systems,
and it works very well. We gather alot of information from bugs and errors that we continuously can improve our product quality.

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!

Thanks & Best Regards
Fredrik Hederstierna

RE: Core file support for ARM none (again)

[Matthew Fortune]

Fredrik Hederstierna <fredrik.hederstierna@verisure.com> writes:
> 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.
* Implementations of the target side stub in something like freertos or
  semi-hosting style code.
* 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.

(I have no say in what is and is not suitable for GDB, these are just
some thoughts)

Regards,
Matthew

RE: Core file support for ARM none (again)

[Fredrik Hederstierna]

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