OpenOCD kills itself instead of exiting normally. This prevents coverage
from working, and profiling might have the same problem. Here's what I did
for coverage:
- Runtime coverage testing
Apply the following patch to prevent OpenOCD from killing itself:
@code
--- a/src/openocd.c
+++ b/src/openocd.c
@@ -372,8 +372,6 @@ int openocd_main(int argc, char *argv[])
if (ERROR_FAIL == ret)
return EXIT_FAILURE;
- else if (ERROR_OK != ret)
- exit_on_signal(ret);
return ret;
}
@endcode
Configure your OpenOCD binary with coverage support as follows:
@code
LDFLAGS="-fprofile-arcs -ftest-coverage"
CFLAGS="-fprofile-arcs -ftest-coverage" ./configure
@endcode
Now every time OpenOCD is run, coverage info in your build directory is
updated. Running `gcov src/path/file.c` will generate a report.
Tim
On Tue, May 18, 2021 at 7:53 AM Ooi, Cinly <[email protected]> wrote:
> Hi
>
>
>
> Does anyone has experience profiling OpenOCD and can share the experience,
> i.e. tools etc?
>
>
>
> The reason for asking is the driver that I am developing, aji_client (
> https://github.com/intel/aji_openocd) is slow under some circumstances.
> Good news is those circumstances are consistently reproducible. I want to
> use profiling tool to identify the bottleneck and where I have to make
> improvement to my driver. The conventional wisdom is to run a profiling
> tool over the workload to get a picture of which functions take the longest
> time, the bottleneck etc instead of stabbing in the dark for solution. I
> tried gprof (1) and sprof (2) and are having issues with them. See notes.
>
>
>
> Many thanks in advance and best regards
>
> Cinly
>
>
>
> Note:
>
> 1. gprof might be the wrong tool to use as my driver calls shared
> library libaji_client.so (https://github.com/intel/libaji_client),
> which for this task I need to profile as well. Chatter on the internet says
> gprof cannot handle shared library
> 2. sprof is giving me problems. I did not manage to get it to work for
> anything more complex than a simple toy program.
>
>
