On Thu, May 24, 2018, 10:46 AM Gedare Bloom <ged...@rtems.org> wrote:
> 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. > I posted one in a new thread yesterday >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
