<div dir="ltr">Hi<div><br></div><div>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 :) )</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>(1) Does not know symbols</div><div>(2) Does not include source code intermixed with disassembly.</div><div><br></div><div>This leaves the final annotated coverage output quite deficient compared to what we have and would want. </div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Just passing along my analysis.</div><div><br></div><div>--joel</div><div><br></div></div>