does rtems 5.1 support create a core dump file when accessing a invalid address or other fatal errors?

[Chris Johns]

On 16/9/20 11:45 am, smallphd at aliyun.com wrote:
> Thanks very much for you reply.  I get many useful information from your suggestion.

No problem.

> Our BSP has a 8MB memory for rtems and a 32MB flash device. So it may not spend
> too much time for dumping the core. 
> The question is that our application running with rtems is very complex. There
> are several threads and many async processes.
> When the fatal error happened, it is possible that the backtrace of current
> thread is not enough.
> We need analyse other data structures to debug, such as all items in a queue or
> some global variable.

That is fine. Complex applications are what we want to hear about. :)

> What's more, when our product sold to consumer and some bugs trigger a crash. We
> could not connect to user's environment to debug.
> So, it will be a better option if a core dump is generated.

You need to capture something but do you need all the memory.

> However, if the core dump policy is not possible, the method you provided is
> feasible.

A core dump might be possible, it is just not currently available. A workable
core would be hard and I suspect would have a number of limitations and it would
take a lot of core developer time to do. Apart of the target capture side we
would need to teach GDB to understand the core image and RTEMS threads so you
could switch threads and provide a backtrace. That alone is a sizeable piece of
work.

> I will study it and check how it will be integrated to our system.

I would select the important data you need to know and then add it to the RTE
struct. What you capture is not limited to what RTEMS provides. You are free to
instrument your application and capture that data on a crash.

Chris