Capstone and Covoar

[Joel Sherrill]

Hi

Alex is getting closer to having covoar working well again and he and I
having audited some results for sanity. Hopefully this will turn into
patches in the next week or so. (putting pressure on him there :) )

Alex did some benchmarking and objdump appears to be taking 75-80% of the
execution time for covoar -- especially when you get to 500+ executables.

Chris and I have discussed using Capstone. I looked at it enough to see
that I do not think it is a replacement for objdump. The blockers are the
quality of output issues:

(1) Does not know symbols
(2) Does not include source code intermixed with disassembly.

This leaves the final annotated coverage output quite deficient compared to
what we have and would want.

>From an operational view, it appears to want a binary blob to dump into
instructions. I think we know the methods entry and length so we can
probably account for this part but the output still is deficient.

The original code did not automatically delete the objdumps. It only ran
objdump if the exe was newer than the dump file. Since covoar is invoked
for each area (e.g. score, rtems, libcsupport, fatfs, etc.), this means it
is running objdump on all executables probably a dozen times. Just
addressing this so we go back to caching the output of dump will eliminate
a LOT of processing time.

Switching to the llvm objdump alternative is an option but if we still are
invoking an executable, it doesn't help.I don't know if they support enough
architectures. If it has a libary interface, I could look at that for
suitability but at this point, I think not deleting the objdump file and
caching it would be a big and quick win.

Note: Eshan and I chatted about this as a potential GSoC project. Capstone
integration is not a potential project. Perhaps llvm objdump has classes
under the hood we could interface with but we need to investigate that
further to know if it is a suitable potential path.

Just passing along my analysis.

--joel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210210/4e4fae93/attachment-0001.html>