This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] libgcov.c re-factoring and offline profile-tool
- From: Xinliang David Li <davidxl at google dot com>
- To: Rong Xu <xur at google dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, Jakub Jelinek <jakub at redhat dot com>, Jan Hubicka <hubicka at ucw dot cz>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 8 Nov 2013 11:13:03 -0800
- Subject: Re: [RFC] libgcov.c re-factoring and offline profile-tool
- Authentication-results: sourceware.org; auth=none
- References: <CAF1bQ=Qy6--WX-bLYZ8aWXjVVu4pW-H3U+PkATgXwg5c7MZsBg at mail dot gmail dot com> <CAAkRFZ+-tLZqUNQRtu7jN3d3BYG8oi-+q0J6pkduHp5GS3oTkQ at mail dot gmail dot com> <20131104095529 dot GB28992 at kam dot mff dot cuni dot cz> <CAF1bQ=THYY8NqoJ0XDYxnFS9=j9P6-5nLwA6nX1bA+0v1zmUoQ at mail dot gmail dot com> <CAAkRFZK-AoS4eKBnoNciHeq5kn5sP60rqyV1dVZVaBte1aW-ew at mail dot gmail dot com> <20131105091850 dot GB13502 at kam dot mff dot cuni dot cz> <20131105092344 dot GF27813 at tucnak dot zalov dot cz> <CAAkRFZK0G61tYeMeVcoOETxhhDWZNnh1Eyf0jeKrTAvsAtZE=A at mail dot gmail dot com> <CAF1bQ=S8m03771H=O7H90mbsCrt1tcknktWYGFCdRF4O-MyF-Q at mail dot gmail dot com> <CAAkRFZ+Be51E2PFPULbNmAh9qQigWTqa04wi8S19ZrPiPwVPiA at mail dot gmail dot com> <CAF1bQ=TyLYDqaWZH3tEw-YODoJMBmt0VVyFaf2+sft2vAxwF_Q at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1311070108410 dot 3878 at digraph dot polyomino dot org dot uk> <CAF1bQ=REYRgX4zn2pwP0HZhg5P0nO3XgXVK=RQVBpFv-o5zoig at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1311071739500 dot 20971 at digraph dot polyomino dot org dot uk> <CAF1bQ=QxT8i=dyKeKor-ze_YADDBQZo+Q2GqiCqOCVSrZKRKaw at mail dot gmail dot com> <CAAkRFZLgA6az1=v4XziUahzHF9Wc0mr2Vk2H=L3Kmq=f4AnRnA at mail dot gmail dot com> <CAF1bQ=Tg+J3ZX2RB8=mEZ0rKJO+7k_LqH+N8uf5+Wa3zia26HA at mail dot gmail dot com> <CAF1bQ=S+SutWXeSj3t9sakECW2=5G7vEtvCW7bamoHmdk2Zt5g at mail dot gmail dot com>
On Fri, Nov 8, 2013 at 10:56 AM, Rong Xu <xur@google.com> wrote:
> A question about inhibit_libc.
> When inhibit_libc is defined, we provide dummy functions for all the
> __gcov_* methods.
> Is it purposely to minimize the footprint?
> I'm thinking to allow some codes that are independent of libc (and its
> headers) under this. Is it OK?
>
I only saw the macro defined for mcore targets -- not sure if they are
obsolete or not.
David
> -Rong
>
> On Fri, Nov 8, 2013 at 10:48 AM, Rong Xu <xur@google.com> wrote:
>> On Fri, Nov 8, 2013 at 10:22 AM, Xinliang David Li <davidxl@google.com> wrote:
>>> in libgcov-driver.c
>>>
>>>> /* Flag when the profile has already been dumped via __gcov_dump(). */
>>>> static int gcov_dump_complete;
>>>
>>>> inline void
>>>> set_gcov_dump_complete (void)
>>>>{
>>> > gcov_dump_complete = 1;
>>>>}
>>>
>>>>inline void
>>>>reset_gcov_dump_complete (void)
>>>>{
>>>> gcov_dump_complete = 0;
>>>>}
>>>
>>>
>>> These should be moved to libgcov-interface.c. Is there reason to not
>>> mark them as static?
>>
>> gcov_dump_complete is used in gcov_exit() which is in
>> libgcov-driver.c, but it's set in __gcov_dump and __gcov_reset, both
>> in libgcov-interface.c.
>> I want gcov_dump_complete a static. So I have to add to global
>> functions that accessible from libgcov-interface.c.
>> Another choice is to move __gcov_dump and __gcov_reset to
>> libgcov-driver.c and that will simplify the code.
>>
>>>
>>> in libgcov-profiler.c, line 142
>>>
>>>> #if defined(HAVE_CC_TLS) && !defined (USE_EMUTLS)
>>>> __thread
>>>
>>> trailing whilte space.
>>>
>>
>> Will fix.
>>
>>>
>>>> || (VTABLE_USES_DESCRIPTORS && __gcov_indirect_call_callee
>>>> && *(void **) cur_func == *(void **) __gcov_indirect_call_callee))
>>>
>>> trailing white space.
>>>
>>
>> Will fix.
>>
>>>
>>> in libgcov-merge.c
>>>
>>> 1) I don't think you need in_mem flag. For in memory merge, the source != NULL.
>>> 2) document the new source and weight parameter -- especially the weight.
>>
>> Will do.
>>
>>> 3) How do you deal with integer overflow ?
>>
>> This is good question. gcvo_type is (typically) long long. I thought
>> the count value will not be nearly close to the max of long long.
>> (We did see overflow in compiler, but that's because of the scaling --
>> some of the scaling factors are really large.)
>>
>>>
>>> David
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Nov 7, 2013 at 3:34 PM, Rong Xu <xur@google.com> wrote:
>>>> On Thu, Nov 7, 2013 at 9:40 AM, Joseph S. Myers <joseph@codesourcery.com> wrote:
>>>>> On Thu, 7 Nov 2013, Rong Xu wrote:
>>>>>
>>>>>> Thanks Joseph for these detailed comments/suggestions.
>>>>>> The fixed patch is attached to this email.
>>>>>> The only thing left out is the Texinfo manual. Do you mean this tool
>>>>>> should have its it's own texi file in gcc/doc?
>>>>>
>>>>> Its own texi file, probably included as a chapter by gcc.texi (like
>>>>> gcov.texi is).
>>>>
>>>> OK. will add this in.
>>>>
>>>> My last patch that changes the command handling is actually broken.
>>>> Please ignore that patch and use the one in this email.
>>>>
>>>> Also did some minor adjust of the code in libgcov.
>>>>
>>>> Thanks,
>>>>
>>>> -Rong
>>>>
>>>>
>>>>>
>>>>> --
>>>>> Joseph S. Myers
>>>>> joseph@codesourcery.com