Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190417225328.208129-1-trong@android.com> <20190417162139.2ca3ba78eab414b2fa854a07@linux-foundation.org>
In-Reply-To: <20190417162139.2ca3ba78eab414b2fa854a07@linux-foundation.org>
From:   Tri Vo <trong@android.com>
Date:   Wed, 17 Apr 2019 16:39:01 -0700
Message-ID: <CANA+-vDZ9VQ--aGGuTSL3ax5Njxm4G9ZqDfMsbmBUJR0dA52Ag@mail.gmail.com>
Subject: Re: [PATCH v5] gcov: Clang support
To:     Andrew Morton <akpm@linux-foundation.org>
Cc:     Greg Hackmann <ghackmann@android.com>,
        Nick Desaulniers <ndesaulniers@google.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Peter Oberparleiter <oberpar@linux.ibm.com>,
        Trilok Soni <tsoni@quicinc.com>,
        Prasad Sodagudi <psodagud@quicinc.com>,
        Daniel Mentz <danielmentz@google.com>,
        Petri Gynther <pgynther@google.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Apr 17, 2019 at 4:21 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Wed, 17 Apr 2019 15:53:28 -0700 Tri Vo <trong@android.com> wrote:
>
> > LLVM uses profiling data that's deliberately similar to GCC, but has a very
> > different way of exporting that data.  LLVM calls llvm_gcov_init() once per
> > module, and provides a couple of callbacks that we can use to ask for more
> > data.
> >
> > We care about the "writeout" callback, which in turn calls back into
> > compiler-rt/this module to dump all the gathered coverage data to disk:
> >
> >    llvm_gcda_start_file()
> >      llvm_gcda_emit_function()
> >      llvm_gcda_emit_arcs()
> >      llvm_gcda_emit_function()
> >      llvm_gcda_emit_arcs()
> >      [... repeats for each function ...]
> >    llvm_gcda_summary_info()
> >    llvm_gcda_end_file()
> >
> > This design is much more stateless and unstructured than gcc's, and is
> > intended to run at process exit.  This forces us to keep some local state
> > about which module we're dealing with at the moment.  On the other hand, it
> > also means we don't depend as much on how LLVM represents profiling data
> > internally.
> >
> > See LLVM's lib/Transforms/Instrumentation/GCOVProfiling.cpp for more
> > details on how this works, particularly GCOVProfiler::emitProfileArcs(),
> > GCOVProfiler::insertCounterWriteout(), and GCOVProfiler::insertFlush().
>
> checkpatch speaketh truth.
>
> Also, I'll change those Co-authored-by's to the documented Co-developed-by.
>
>
> From: Andrew Morton <akpm@linux-foundation.org>
> Subject: gcov-clang-support-checkpatch-fixes
>
> WARNING: Non-standard signature: Co-authored-by:
> #31:
> Co-authored-by: Nick Desaulniers <ndesaulniers@google.com>
>
> WARNING: Non-standard signature: Co-authored-by:
> #32:
> Co-authored-by: Tri Vo <trong@android.com>
>
> WARNING: Possible unnecessary 'out of memory' message
> #158: FILE: kernel/gcov/clang.c:90:
> +       if (!info) {
> +               pr_warn_ratelimited("failed to allocate gcov info\n");
>
> WARNING: Possible unnecessary 'out of memory' message
> #193: FILE: kernel/gcov/clang.c:125:
> +       if (!info) {
> +               pr_warn_ratelimited("failed to allocate gcov function info for %s\n",
>
> WARNING: line over 80 characters
> #546: FILE: kernel/gcov/clang.c:478:
> +                       pos += store_gcov_u32(buffer, pos, fi_ptr->cfg_checksum);
>
> total: 0 errors, 5 warnings, 663 lines checked
>
> NOTE: For some of the reported defects, checkpatch may be able to
>       mechanically convert to the typical style using --fix or --fix-inplace.
>
> ./patches/gcov-clang-support.patch has style problems, please review.
>
> NOTE: If any of the errors are false positives, please report
>       them to the maintainer, see CHECKPATCH in MAINTAINERS.
>
> Please run checkpatch prior to sending patches

Thanks! I'll keep that in mind.