On Thu, May 24, 2018 at 9:05 AM, Joel Sherrill <j...@rtems.org> wrote: > > > On Thu, May 24, 2018, 8:04 AM Gedare Bloom <ged...@rtems.org> wrote: >> >> On Wed, May 23, 2018 at 2:28 AM, Sebastian Huber >> <sebastian.hu...@embedded-brains.de> wrote: >> > On 23/05/18 01:06, Joel Sherrill wrote: >> >> >> >> Or we may need to limit ourselves to source line mapping on a per >> >> executable >> >> basis. And generate reports using gcov output if we see methods change >> >> between executables. I have shied away from gcov as the primary format >> >> because I don't see how to do subexpression analysis. >> >> >> >> if (a == 0 || b == 1) >> >> >> >> That's one line of source but two sub-expressions. Unless it's changed >> >> recently, the debug info is not at a level of granularity to generate >> >> gcov data that can tell we always too the first sub-expression. >> >> >> >> I'm not arguing -- just saying that doing the analysis at the asm level >> >> gives us branch information I don't think we get via source line >> >> analysis and gcov. >> > >> > >> > Is the --all-blocks option of gcov helpful here? >> > >> > https://gcc.gnu.org/onlinedocs/gcc/Invoking-Gcov.html#Invoking-Gcov >> > >> >> Yes, that seems like it should work to me. > > > Can you decipher the gcov output to see if it is working?
Not immediately, but maybe you can put together a simple example of a subexpr that is 'dead code' to test with/without the option. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
