LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 32274 - XRay should not use C++ standard libraries internally
Summary: XRay should not use C++ standard libraries internally
Status: RESOLVED FIXED
Alias: None
Product: XRay
Classification: Unclassified
Component: Runtime (show other bugs)
Version: unspecified
Hardware: All All
: P normal
Assignee: Dean Michael Berris
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-14 19:29 PDT by Dean Michael Berris
Modified: 2018-06-07 21:41 PDT (History)
3 users (show)

See Also:
Fixed By Commit(s):


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dean Michael Berris 2017-03-14 19:29:14 PDT
As reported by David Blaikie in llvm-dev@ (see http://lists.llvm.org/pipermail/llvm-dev/2017-March/110835.html)

Action items:
- Remove dependency on standard C++ library symbols for XRay's runtime
- Use functional equivalents to std::atomic<...>, containers, and C++11+'s thread_local keyword
Comment 1 Dean Michael Berris 2017-03-27 19:03:42 PDT
Fixed as of https://reviews.llvm.org/rL298835.

Not only have we removed the runtime dependency on the C++ standard library runtime, but also removed some uses of std::atomic<...> that might prove problematic in some cases.
Comment 2 David Blaikie 2017-03-28 08:07:31 PDT
(In reply to Dean Michael Berris from comment #1)
> Fixed as of https://reviews.llvm.org/rL298835.
> 
> Not only have we removed the runtime dependency on the C++ standard library
> runtime,

That's not guaranteed though, is it? If you use any C++ library features, they might rely on runtime support from some library that needs to be linked in. The one(s) that've been used so far don't appear to, but it doesn't make this solidly portable (granted, there's no guarantee that some compiler doesn't produce binaries that need a C++ runtime support library even if they use no library features at all - but that's perhaps a bit less likely).

I'm not too fussed personally - but suspect that it's probably still right/proper to remove all C++ library dependencies unless there's a way to do what Chandler had mentioned a while back - statically linking in a privately mangled version of the standard library.

>  but also removed some uses of std::atomic<...> that might prove
> problematic in some cases.
Comment 3 Dean Michael Berris 2017-10-22 20:34:32 PDT
Re-opening to reflect the most recent state: we should not be using anything from the C++ standard library. This is based on the conversation we've had in llvm-dev@:

http://lists.llvm.org/pipermail/llvm-dev/2017-October/118126.html

In particular:

"""
The sanitizers don't use any of the C++ std library.
More than that, they don't include *any* system headers in most of the
sources (exception is some OS-dependent .cc files).

This rule is *somewhat* documented, e.g.
tsan/rtl/tsan_rtl.h:

//   - No system headers included in header files (*).
//   - Platform specific headres included only into platform-specific files
(*).
"""

http://lists.llvm.org/pipermail/llvm-dev/2017-October/118132.html
Comment 4 Dean Michael Berris 2018-03-16 00:38:34 PDT
Recent work on this has removed all dependencies to standard library dependencies.
Comment 5 Dean Michael Berris 2018-04-12 23:00:31 PDT
Unfortunately, we're still relying on some C++ specific functionality, some of which are provided by libcxxabi, but I'd like to explore the possibility of removing those first/instead.

This came up in a discussion with why we're failing to link C programs with XRay instrumentation. Reopening this bug so that we can address this in either the runtime, or even in Clang.
Comment 6 Dean Michael Berris 2018-06-07 21:41:01 PDT
This is now fixed by https://reviews.llvm.org/rL334262 (r334262).