[llvm] r342518 - [XRay][compiler-rt] FDRLogWriter Abstraction

Wed Sep 19 17:38:26 PDT 2018

Ah -- wow, that looks like a missing -I somewhere. Let me fix that and
attempt to re-land.

Thanks!

On Thu, Sep 20, 2018 at 10:33 AM Evgenii Stepanov <eugeni.stepanov at gmail.com>
wrote:

> It's easy to reproduce by adapting a cmake line from
>
> http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/15734/steps/build%20standalone%20compiler-rt/logs/stdio
>
> On Wed, Sep 19, 2018 at 5:32 PM, Evgenii Stepanov <
> eugeni.stepanov at gmail.com> wrote:
>
>> It not help.
>> For me, the compilation command line ends with
>> -I/code/llvm-project/compiler-rt/lib/xray
>> -I/code/llvm-project/compiler-rt/lib -I/code/llvm-project/llvm/include
>> -I/code/llvm-project/llvm/include /code/build-llvm/include -m64 -c -o
>> TEST_OBJECTS.profile_collector_test.cc.x86_64.o
>> /code/llvm-project/compiler-rt/lib/xray/tests/unit/profile_collector_test.cc
>>
>> See the argument before -m64.
>>
>> On Wed, Sep 19, 2018 at 4:54 PM, Dean Michael Berris <dberris at google.com>
>> wrote:
>>
>>> That error is not terribly helpful though -- which linker argument is
>>> not used?
>>>
>>> I attempted a fix for this in https://reviews.llvm.org/rL342523, did
>>> that not fix the issue for the standalone build?
>>>
>>> On Thu, Sep 20, 2018 at 8:31 AM Evgenii Stepanov <
>>> eugeni.stepanov at gmail.com> wrote:
>>>
>>>> Reverted in r342596.
>>>>
>>>> On Wed, Sep 19, 2018 at 3:10 PM, Evgenii Stepanov <
>>>> eugeni.stepanov at gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> this is failing on the bot:
>>>>>
>>>>> http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/15732/steps/test%20standalone%20compiler-rt/logs/stdio
>>>>>
>>>>> clang-8: error: /b/sanitizer-x86_64-linux/build/llvm_build64/include: 'linker' input unused [-Werror,-Wunused-command-line-argument]
>>>>>
>>>>>
>>>>> The compiler (with -c flag) command line includes the path mentioned
>>>>> above without -I .
>>>>> I'm not sure how that happens, but reverting this change (along with
>>>>> another one that depends on it) helps.
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Sep 18, 2018 at 4:59 PM, Dean Michael Berris via llvm-commits
>>>>> <llvm-commits at lists.llvm.org> wrote:
>>>>>
>>>>>> Author: dberris
>>>>>> Date: Tue Sep 18 16:59:32 2018
>>>>>> New Revision: 342518
>>>>>>
>>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=342518&view=rev
>>>>>> Log:
>>>>>> [XRay][compiler-rt] FDRLogWriter Abstraction
>>>>>>
>>>>>> Summary:
>>>>>> This change introduces an `FDRLogWriter` type which is responsible for
>>>>>> serialising metadata and function records to character buffers. This
>>>>>> is
>>>>>> the first step in a refactoring of the implementation of the FDR
>>>>>> runtime
>>>>>> to allow for more granular testing of the individual components of the
>>>>>> implementation.
>>>>>>
>>>>>> The main contribution of this change is a means of hiding the details
>>>>>> of
>>>>>> how specific records are written to a buffer, and for managing the
>>>>>> extents of these buffers. We make use of C++ features (templates and
>>>>>> some metaprogramming) to reduce repetition in the act of writing out
>>>>>> specific kinds of records to the buffer.
>>>>>>
>>>>>> In this process, we make a number of changes across both LLVM and
>>>>>> compiler-rt to allow us to use the `Trace` abstraction defined in the
>>>>>> LLVM project in the testing of the runtime implementation. This gives
>>>>>> us
>>>>>> a closer end-to-end test which version-locks the runtime
>>>>>> implementation
>>>>>> with the loading implementation in LLVM.
>>>>>>
>>>>>> We also allow using gmock in compiler-rt unit tests, by adding the
>>>>>> requisite definitions in the `AddCompilerRT.cmake` module.
>>>>>>
>>>>>> Finally, we've gone ahead and updated the FDR logging implementation
>>>>>> to
>>>>>> use the FDRLogWriter for the lowest-level record-writing details.
>>>>>>
>>>>>> Following patches will isolate the state machine transitions which
>>>>>> manage the set-up and tear-down of the buffers we're using in multiple
>>>>>> threads.
>>>>>>
>>>>>> Reviewers: mboerger, eizan
>>>>>>
>>>>>> Subscribers: mgorny, jfb, llvm-commits
>>>>>>
>>>>>> Differential Revision: https://reviews.llvm.org/D52220
>>>>>>
>>>>>> Modified:
>>>>>>     llvm/trunk/include/llvm/XRay/Trace.h
>>>>>>
>>>>>> Modified: llvm/trunk/include/llvm/XRay/Trace.h
>>>>>> URL:
>>>>>> http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/XRay/Trace.h?rev=342518&r1=342517&r2=342518&view=diff
>>>>>>
>>>>>> ==============================================================================
>>>>>> --- llvm/trunk/include/llvm/XRay/Trace.h (original)
>>>>>> +++ llvm/trunk/include/llvm/XRay/Trace.h Tue Sep 18 16:59:32 2018
>>>>>> @@ -46,20 +46,25 @@ namespace xray {
>>>>>>  ///
>>>>>>  class Trace {
>>>>>>    XRayFileHeader FileHeader;
>>>>>> -  std::vector<XRayRecord> Records;
>>>>>> +  using RecordVector = std::vector<XRayRecord>;
>>>>>> +  RecordVector Records;
>>>>>>
>>>>>>    typedef std::vector<XRayRecord>::const_iterator citerator;
>>>>>>
>>>>>>    friend Expected<Trace> loadTrace(const DataExtractor &, bool);
>>>>>>
>>>>>>  public:
>>>>>> +  using size_type = RecordVector::size_type;
>>>>>> +  using value_type = RecordVector::value_type;
>>>>>> +  using const_iterator = RecordVector::const_iterator;
>>>>>> +
>>>>>>    /// Provides access to the loaded XRay trace file header.
>>>>>>    const XRayFileHeader &getFileHeader() const { return FileHeader; }
>>>>>>
>>>>>> -  citerator begin() const { return Records.begin(); }
>>>>>> -  citerator end() const { return Records.end(); }
>>>>>> +  const_iterator begin() const { return Records.begin(); }
>>>>>> +  const_iterator end() const { return Records.end(); }
>>>>>>    bool empty() const { return Records.empty(); }
>>>>>> -  size_t size() const { return Records.size(); }
>>>>>> +  size_type size() const { return Records.size(); }
>>>>>>  };
>>>>>>
>>>>>>  /// This function will attempt to load XRay trace records from the
>>>>>> provided
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> llvm-commits mailing list
>>>>>> llvm-commits at lists.llvm.org
>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>>>>>
>>>>>
>>>>>
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180920/c6ab585b/attachment.html>