Feature/gdb backtrace with params

[lukzeg]

---

FEATURE
Extend collecting backtrace data from crashing test_runner executable file.
After setting up project.yml:

:project:
  :use_backtrace_gdb_reporter: TRUE

...

:test_runner:
  :cmdline_args: true

Ceedling engine is executing test separatelly in the test file, which is crashing.

What that means?

1. If file is crashing on one test case, rest of test cases will be executed. The test results will be collected. The test which cause segmentation fault is executed and marked as failure. The backtrace is added as failure reason.
2. The *.gcno and *.gcda files are created and the code coverage is computing collected data from rest of test cases. The blank side is touching only test code execution, which is causing segmentation fault
3. Running on only test case which cause segmentation fault, decrease amount of time execution and create fail file together with backtrace as help for further investigation.

---

PR includes

Updated code :

• Added new class debugging_utils.rb. (no code style issues - tested via rubocop)
• Updated implementation of generator.rb
• Updated implementation or generator_test_results.rb
• Updated unity_utils.rb

Updated CeedlingPacket.md with new ceedling functionality.

Added 5 UT to cover new functionality. ( rubocop describe problems with to long name description)

---

Short description

This PR contains extension for backtrace collector which enable possibility to collect test results from crashing test_runner file and creating test report files.

As well enable running separate test cases form crashing test runner. This logic enables creation of *.gcda and *.gcno files required by GCOV to generate coverage data

ceedling test:<test_file_name> --test_case=<test_case_name>
ceedling gcov:all
cedling utils:gcov

and updating project.yml after adding:

:project:
  :use_backtrace_gdb_reporter: TRUE

...

:test_runner:
  :cmdline_args: true

Limitations and problems:

• If test_runner file contains a lot of test cases, the time execution on it can be increased, as each of test case will be executed separately and the possible new problems, such as test case dependency might appears.

---

** How it works in real life **

If test file contains three test cases:
test_gpio.c

#include "unity.h"
#include "gpio_def.h"
#include <signal.h>

void setUp(void) {}
void tearDown(void) {}

void test_gpio_start(void) {
  TEST_ASSERT_EQUAL(GPIO_OK, gpio_start(gpio13) ).
}

void test_gpio_configure_proper(void) {
  raise(SIGSEGV);
  TEST_ASSERT_EQUAL(GPIO_OK, gpio_configure(gpio_13, NULL));
}


void test_gpio_configure_fail_pin_not_allowed(void) {
  TEST_ASSERT_EQUAL(GPIO_ERR, gpio_configure(gpio_max, NULL));
}

if we run ceedling on it with enabled in project.yml:
project.yml after adding:

:project:
  :use_backtrace_gdb_reporter: TRUE

...

:test_runner:
  :cmdline_args: true

after discovering segmentation fault, thanks to enabled by cmdline_args Unity functionality, all test names will be collected from crashing test_runner file.

Each test will be executed separately in gdb (which will produce backtrace on segmentation fault) and test results (and log - keep in mind xunit has possibility of failure description) will be save and computed in one test report as Ceedling is producing during normal test execution flow. This will extend the execution time for test files with many test_cases only in case of segmentation faulted test case, but it will end up producing a valuable report about the failure.

As well the end developer receive possibility to run and get backtrace data from failing test case running:

ceedling test:all --test_case=test_gpio_configure_proper

which will produce backtrace to help engineer to investigate segmentation fault reason.

---

@mvandervoord : Can I ask you for a looking at this in your free time? I have hope that this feature will help other people as helped me in my day work.

[mvandervoord]

I'll dig into this as soon as I can. At the moment, I'm focusing most of my attention on the 0.32 release candidate branch, which contains your previous work on this. :)

[lukzeg]

Sure, fully understand. No worries and please let me know if you need any helping hand. One more time, thank you for your time. :)

[lukzeg]

This PR is an proposal of fixing issue described in : #185

[Letme]

I read the description and it would be better if:

Each of test will be executed separately and test results will be saved and computed in the one test report as Ceedling is producing during normal test execution flow.

would be:

Each test will be executed separately in gdb (which will produce backtrace on segmentation fault) and test results (and log - keep in mind xunit has possibility of failure description) will be save and computed in one test report as Ceedling is producing during normal test execution flow. This will extend the execution time for test files with many test_cases only in case of segmentation faulted test case, but it will end up producing a valuable report about the failure.

In that way it covers also the issue #185 completely and it does not require another run from developer (helps when failure is in CI and you dont need to do another run).

[Letme]

I reviewed non-ruby part, as I am not really a Ruby developer, but it might be helpful for starting a discussion.

[mvandervoord]

It's looking really great. Thanks for doing all of this work. This is an excellent feature!

I left some comments. When you're feeling like this is ready, I'm going to cherry-pick the changes to test/ceedling_0_32_rc. I'm getting close to merging all of this to the main branch and releasing 0.32 and I'd like this to be part of it... but you'll see it's diverged a bit (primarily because of the multitasking support).

[mvandervoord]

Thanks, this is looking great. Anyone else have anything else to say before I start merging?

[Letme]

Fine for me.

[mvandervoord]

Merged into PR #739