Re: [RFC] libgcov.c re-factoring and offline profile-tool

[Xinliang David Li <davidxl at google dot com>]

I have not looked this in detail, but it looks like the copy right
header of the new file is wrong (including the year).

You should 1) document the command line syntax somewhere, possibly in
comment?  2) add a help command for the tool to dump out help message.

David

On Wed, Nov 6, 2013 at 1:25 PM, Rong Xu <xur@google.com> wrote:
> Here is the patch that includes profile-tool.
> Profile-tool now has two functions: merge and rewrite. I'll add diff later.
>
> Compiler is tested with spec2006 and profiledbootstrap.
> profile-tool is tested with spec2006 profiles.
>
> -Rong
>
> On Tue, Nov 5, 2013 at 8:58 AM, Xinliang David Li <davidxl@google.com> wrote:
>> Those functions are not referencing each other, but they get used in
>> different logical groups, so at least control granularity can be
>> improved. For instance,
>> 1) all gcov user interfaces such as gcov_dump, gcov_flush, gcov_reset
>> are either not used at all, or all of them are used -- there is no
>> need to split this group. After Rong's refactoring (move them into a
>> separate file), the guarding macro can be removed for them
>> 2) _gcov_merge_add is used by 4 different profilers, so it is almost
>> always linked in
>>
>> It is unclear how other value profilers are used on other targets. For
>> x86, they are on by default, so the profiler bodies and merge
>> functions are also always linked in.
>>
>> David
>>
>> On Tue, Nov 5, 2013 at 1:23 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>>> On Tue, Nov 05, 2013 at 10:18:50AM +0100, Jan Hubicka wrote:
>>>> > I wonder if it makes sense to get rid of the conditional compile such as
>>>> >
>>>> > #ifdef L_gcov_xxxxx
>>>> > ..
>>>> >
>>>> > #endif
>>>> >
>>>> > This has the advantage of producing slightly smaller instrumented
>>>> > binary, but this benefit can also be achieved via -ffunction-sections
>>>> > and let linker to garbage collect unused functions.
>>>> >
>>>> > (probably as a follow up if it makes sense).
>>>>
>>>> I believe we use this funny scheme primarily for targets that have no function
>>>> section support (and also the hand made splitting can be more sane).
>>>> For a low-level library like libgcov is that is supposed to have small footprint,
>>>> I guess the current scheme is resonable thing to do....
>>>
>>> I think the #ifdef L* stuff is there mainly so that we have small
>>> granularity in the *.a libraries (one function per object file), so that one
>>> links only what is really required (at least, that is why libgcc.a does
>>> that).  Of course, if there are many interdependencies between the functions
>>> and you always essentially link in everything, the usefulness of that is
>>> lower.
>>>
>>>         Jakub