On 16/9/20 11:45 am, small...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
