[llvm-dev] Using C++ and sanitizer_common in profile runtime

[Xinliang David Li via llvm-dev]

I actually meant 'runtime_common'.

David

On Wed, Jul 14, 2021 at 5:07 PM Vedant Kumar <vsk at apple.com> wrote:

> On Jul 14, 2021, at 4:56 PM, Xinliang David Li <davidxl at google.com> wrote:
>
>
> Can we introduce C wrappers to sanitizer_common and use them in profile
> runtime? Of course 'sanitizer_common' needs to become 'profile_common'.
>
>
> I like the sound of 'runtime_common' a bit better (sorry for the bikeshed
> :).
>
> vedant
>
>
>
> David
>
> On Wed, Jul 14, 2021 at 4:14 PM Petr Hosek <phosek at google.com> wrote:
>
>> What are your thoughts on using C++ and sanitizer_common in profile
>> runtime?
>>
>> First, to clarify, I'm not suggesting using the standard C++ library.
>> What I'm suggesting is just using the C++ language akin to sanitizer
>> runtimes or memprof.
>>
>> profile runtime is the last major runtime in compiler-rt that's
>> implemented in C and switching to C++ could make the compiler-rt codebase
>> more uniform. Beyond that, I think this could be beneficial for several
>> reasons:
>>
>> * _Reducing the duplication between profile runtime and
>> sanitizer_common._ Both of these implement various polyfills for different
>> platforms (for example the mmap like interface) and it would be great if we
>> could avoid duplicating the effort and share a common implementation.
>>
>> * _Avoiding potential cyclic dependencies in profile runtime._ The
>> implementation currently uses various libc functions, but if libc is
>> profile instrumented there is a risk of potentially entering an infinite
>> recursion. This could be avoided by using internal implementations of these
>> libc functions which sanitizer_common does, but if we wanted to take the
>> same approach for profile runtime, we would need to re-implement these
>> functions again further increasing duplication.
>>
>> * _Simplifying the profile runtime implementation._ Some parts of the
>> runtime already use object-oriented style interfaces, that is structs with
>> function pointers, replacing these with classes would make the code
>> cleaner. Furthermore, we could use classes to abstract away some of the
>> platform implementation which currently relies on ifdefs. We could also
>> take the advantage of RAII for resource management.
>>
>> If we decided to go ahead with this change, I'd suggest an incremental
>> transition rather than doing a major rewrite. We would start by ensuring
>> that all source files compile as C++. Then we would introduce the
>> sanitizer_common dependency and see which functions could be replaced by
>> sanitizer_common counterparts. Finally, we could refactor the
>> implementation and take advantage of C++ constructs where appropriate.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210714/0e83ac13/attachment.html>