libcxxrt / libcxxrt Goto Github PK

License: Other

C 49.53% C++ 47.64% Shell 0.04% CMake 2.78%

libcxxrt's Introduction

libcxxabi
=========

This library implements the Code Sourcery C++ ABI, as documented here:

http://www.codesourcery.com/public/cxx-abi/abi.html

It is intended to sit below an STL implementation, and provide features required by the compiler for implementation of the C++ language.

Current Status
--------------

At present, the library implements the following parts of the ABI specification:

- RTTI classes and support for the dynamic_cast<> operator.
- Exception handling.
- Thread-safe initializers.

Exception handling requires the assistance of a stack-unwinding library
implementing the low-level parts of the ABI. Either libgcc_s or libunwind
should work for this purpose.

The library depends on various libc features, but does not depend on any C++
features not implemented purely in the compiler or in the library itself.

Supported Platforms
-------------------

This code was initially developed on FreeBSD/x86, and has also been tested on FreeBSD/x86-64. It should work on other platforms that use the Code Sourcery ABI, for example Itanium, however this is untested.

This library also supports the ARM EH ABI.

Installation
------------

The default build system does not perform any installation. It is expected that this will be done by at a higher level. The exact installation steps depend on how you plan on deploying libcxxrt.

There are three files that you may consider installing:

- cxxabi.h (and unwind.h and either unwind-arm.h or unwind-itanium.h)
- libcxxrt.a
- libcxxrt.so

The first describes the contract between this library and the compiler / STL implementation (lib[std]{cxx,c++}). Its contents should be considered semi-private, as it is probably not a good idea to encourage any code above the STL implementation to depend on it. Doing so will introduce portability issues. You may install this file but I recommend simply copying or linking it into your STL implementation's build directory.

In general, I recommend against installing both the .a and the .so file. For static linking, the .a file should be linked against the static and dynamic versions of your STL implementation. Statically linking libcxxrt into your STL implementation means that users who dynamically link against the STL implementation can have libcxxrt upgraded automatically when you ship a new version of your STL implementation.

The other option, installing the .so, is recommended for situations where you have two or more STL implementations and wish to be able to link against both (e.g. where an application links one library using libstdc++ and another using libc++). To support this case, you should link both STL implementations against libcxxrt.so.

Supporting all of these options in the CMake build system is not practical - the amount of effort required to select the one that you want would be more than the effort required to perform the installation from an external script or build system.

libcxxrt's People

Contributors

Stargazers

Watchers

libcxxrt's Issues

Please finish WordGuard comment

libcxxrt/src/guard.cc

Line 71 in 6229590

* On many 32-bit platforms, 64-bit atomics are unavailable (or slow) and so we

This comment starts with:

On many 32-bit platforms, 64-bit atomics are unavailable (or slow) and so we treat the two halves of the 64-bit word as independent values and

but never finishes the sentence! I'm dying with curiosity to know the conclusion :)

Demangler update broke type demangling

Since #3 was merged, types are no longer demangled. It seems like the elftc sources only handle functions and the change to handle types (18482f1) was reverted.

CC: @DimitryAndric

__cxa_guard_acquire should use atomic acquire ordering for the fast path

As the comment says, an non-atomic read does not establish a happens-before relationship. However, the intention of the standard is that such a relationship should be established.

A thread-safe implementation will probably guard access to the first byte of the guard_object with a mutex. If this function returns 1, the mutex will have been acquired by the calling thread.

Both libstdc++ libsupc++ and libc++abi use atomic acquire ordering.

/**
 * Acquires a lock on a guard, returning 0 if the object has already been
 * initialised, and 1 if it has not.  If the object is already constructed then
 * this function just needs to read a byte from memory and return.
 */
extern "C" int __cxa_guard_acquire(volatile guard_t *guard_object)
{
        guard_lock_t old;
        // Not an atomic read, doesn't establish a happens-before relationship, but
        // if one is already established and we end up seeing an initialised state
        // then it's a fast path, otherwise we'll do something more expensive than
        // this test anyway...
        if (INITIALISED == *INIT_PART(guard_object))
                return 0;

Update link from readme

Seems link http://www.codesourcery.com/public/cxx-abi/abi.html now doesn't work

Feature request: __cxa_init_primary_exception

Hi!

Currently, libc++ does this in std::make_exception_ptr:

try {
  throw __e;
} catch (...) {
  return current_exception();
}

when libstdc++ does this:

using _Ex2 = typename decay<_Ex>::type;
void* __e = __cxxabiv1::__cxa_allocate_exception(sizeof(_Ex));
// --------------------------------- libsupc++ extension:
(void) __cxxabiv1::__cxa_init_primary_exception(
    __e, const_cast<std::type_info*>(&typeid(_Ex)),
    __exception_ptr::__dest_thunk<_Ex2>);
// ------------------------------------------------------
__try
{
  ::new (__e) _Ex2(__ex);
  return exception_ptr(__e);
}
__catch(...)
{
  __cxxabiv1::__cxa_free_exception(__e);
  return current_exception();
}

The idea is that instead of going through full unwinding cycle, one could just allocate and initialize an exception directly, with __cxa_init_primary_exception being an extension function in libsupc++.

std::make_exception_ptr is widely used with std::promise::set_exception in all kinds of async processing,
and implementing it via __cxa_init_primary_exception not only makes it an order of magnitude faster,
but also avoids a potential global lock, which unwinders tend to acquire (see https://isocpp.org/files/papers/P2544R0.html#problems, https://reviews.llvm.org/D130668, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744 etc.).

I'm currently talking with developers of llibc++/ibc++abi about the same change, and if i'll manage to convince them it would be nice to have this implemented in libcxxrt as well.

The change proposed is very straightforward:
move exception initialization from __cxa_throw to __cxa_init_primary_exception, add [unexpected/terminate]Handler initialization, call the new function from __cxa__throw.

Does this sound reasonable to you?
Would you be willing to accept such a patch, once (hopefully) libc++/libc++api implements it as well?

Processes hang on FreeBSD/i386 after fd484be

https://lists.freebsd.org/archives/dev-commits-src-all/2022-March/008441.html

After this merge [of upstream libcxxrt], some i386 c++ processes are hanging.

@DimitryAndric writes:

I could reproduce a CMake hang with poppler-qt5, and it turns out that
libcxxrt's fd484be can make __cxa_guard_acquire hang on i386.

libcxxrt / libcxxrt Goto Github PK

libcxxrt's Introduction

libcxxrt's People

Contributors

Stargazers

Watchers

Forkers

libcxxrt's Issues

Please finish WordGuard comment

Demangler update broke type demangling

__cxa_guard_acquire should use atomic acquire ordering for the fast path

Update link from readme

Feature request: __cxa_init_primary_exception

Processes hang on FreeBSD/i386 after fd484be

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent

Jobs