On 25/05/18 07:54, Sebastian Huber wrote:
On 24/05/18 17:46, Gedare Bloom 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.
It seems that gcov already produces sub-expression branch counts
without the -a option:
Actually, I think this is more a feature of the GCC -fprofile-arcs
-ftest-coverage options.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
