Symbol Size Variance

[Joel Sherrill]

On Thu, May 24, 2018, 10:46 AM Gedare Bloom <gedare at rtems.org> wrote:

> On Thu, May 24, 2018 at 9:05 AM, Joel Sherrill <joel at rtems.org> wrote:
> >
> >
> > On Thu, May 24, 2018, 8:04 AM Gedare Bloom <gedare at rtems.org> wrote:
> >>
> >> On Wed, May 23, 2018 at 2:28 AM, Sebastian Huber
> >> <sebastian.huber at 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

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180524/db1d5e66/attachment-0002.html>