[llvm-dev] Using source-based code coverage on baremetal

ORiordan, Martin via llvm-dev llvm-dev at lists.llvm.org
Tue Sep 12 03:14:09 PDT 2017


Hi Eli,

What we have done is inserted calls to:

   lprofSetupValueProfiler()
   __llvm_profile_initialize_file()

before execution, and:

   __llvm_profile_write_file()

after execution to ensure that the functionality of the 'RegisterRuntime' and 'atexit' are preserved.  I must admit I did not drill deeper to see if this was necessary at all, we are still at the prototype stage of this work, although at an advanced stage (it does actually work ;-).  I will have to experiment to see if these calls are necessary at all, and if not simplify our solution.  We do however "fake" some file functionality to get the profiling working, but a non-file based approach would be way better.

Rather than inserting code to call these, we are using a combination of 'objcopy' to rename the entry-point to the program, and use a shim with the original name which calls the profile initialisation functions before calling the user's original renamed entry-point.  Similarly another shim for termination.  This is what I meant by "smoke and mirrors", but it is effective and does not require special alteration to the program source.

Needless to say, a proper bona-fide mechanism for doing this in the embedded space would be way preferred.

The essential elements (as I see it) for the various compiler-rt instrumentation support is:

1.  A simple hook to ensure that the data structures
    structures involved in the instrumentation are
    properly initialised
2.  Another hook to allow the system to offload the
    instrumentation data
3.  Offline tools/utilities on the host system to
    aggregate and collate the data produced by
    multiple runs - this could possibly be achieved
    by extending the functionality of 'llvm-profile'.
    I didn't realise that 'llvm-profile' already had
    support for merging multiple data sets, I will
    have to learn how to do that - thanks for the tip

We still haven't experimented with incrementally offloading the instrumentation data during execution, and that would be a very neat capability.

Thanks,

    MartinO

-----Original Message-----
From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Friedman, Eli via llvm-dev
Sent: Monday, September 11, 2017 8:56 PM
To: Martin J. O'Riordan <MartinO at theheart.ie>; 'Jonathan Roelofs' <jonathan at codesourcery.com>; 'Vedant Kumar' <vsk at apple.com>; weimingz at codeaurora.org; 'LLVM Developers' <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Using source-based code coverage on baremetal

On 9/11/2017 2:37 AM, Martin J. O'Riordan wrote:
> We also have to ensure that the basic instrumentation initialisation process normally handled by 'RegistrationRuntime Registration' is performed before the program is allowed execute, and that the data is subsequently dumped (taken off-chip) after execution.  This is done with a bit of smoke and mirrors as many programs in the embedded environment to not have support for running the '.ctors' functions before and the 'atexit' functions after execution (especially C programs).

I don't think RegisterRuntime provides any relevant functionality unless you're writing to a file (I didn't even realize that existed before now).

We've been modifying the source code to write out profile data because our images never actually "exit".  Maybe there's something more clever we can do in some cases.

> But the Compiler-RT profile library also integrates the automatic merging and collation of data from multiple runs within the library implementation itself, and this is a really significant problem for base-metal system with no OS and no file-system.  It does this using "patterns" in the file name (derived from the environment), and the data collation performed by the system being profiled.
>
> I think that to better facilitate bare-metal systems, this process of collating the results of multiple runs would be best provided by a separate stand-alone utility on the host system that would perform this logic offline rather than having it integrated online as it is currently defined.

The logic for merging raw profiles already exists in llvm-profdata (see https://llvm.org/docs/CommandGuide/llvm-profdata.html#profdata-merge ).

-Eli

--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.


More information about the llvm-dev mailing list