Fix: x86 and s390 uatomic: __hp() macro warning with gcc 11

[urcu.git] / README.md

diff --git a/README.md b/README.md
index 7a33cd7ea044c138618d886f50325661ff757105..02b903a2e18ea9d533cc4cd31e0b6288a32cc3b6 100644 (file)
--- a/README.md
+++ b/README.md
@@ -58,7 +58,7 @@ Tested on:
   - FreeBSD 8.2/8.3/9.0/9.1/10.0 i386/amd64
   - Solaris 10/11 i386
   - Cygwin i386/amd64
-  - MacOSX amd64
+  - MacOS amd64/arm64
 
 Should also work on:
 
@@ -86,19 +86,13 @@ supported, with the following exceptions:
   - Alpha, ia64 and ARM architectures depend on GCC 4.x with atomic builtins
     support. For ARM this was introduced with GCC 4.4:
     http://gcc.gnu.org/gcc-4.4/changes.html.
+  - Linux aarch64 depends on GCC 5.1 or better because prior versions
+    perform unsafe access to deallocated stack.
 
 Clang version 3.0 (based on LLVM 3.0) is supported.
 
-Building on MacOS X (Darwin) requires a work-around for processor
-detection:
-
-  - 32-bit:
-
-        ./configure --build=i686-apple-darwin11
-
-  - 64-bit:
-
-        ./configure --build=x86_64-apple-darwin11
+Glibc >= 2.4 should work but the older version we test against is
+currently 2.17.
 
 For developers using the Git tree:
 
@@ -106,7 +100,7 @@ This source tree is based on the autotools suite from GNU to simplify
 portability. Here are some things you should have on your system in order to
 compile the git repository tree :
 
-  - GNU autotools (automake >=1.10, autoconf >=2.50, autoheader >=2.50)
+  - GNU autotools (automake >=1.12, autoconf >=2.69)
     (make sure your system wide `automake` points to a recent version!)
   - GNU Libtool >=2.2
     (for more information, go to http://www.gnu.org/software/autoconf/)
@@ -224,10 +218,11 @@ be overridden with `-DSIGRCU` by modifying `Makefile.build.inc`.
 
 The BP library flavor stands for "bulletproof". It is specifically
 designed to help tracing library to hook on applications without
-requiring to modify these applications. `urcu_bp_init()`,
-`urcu_bp_register_thread()` and `urcu_bp_unregister_thread()` all become
-nops. The state is dealt with by the library internally at the expense
-of read-side and write-side performance.
+requiring to modify these applications. `urcu_bp_init()`, and
+`urcu_bp_unregister_thread()` all become nops, whereas calling
+`urcu_bp_register_thread()` becomes optional. The state is dealt with by
+the library internally at the expense of read-side and write-side
+performance.
 
 
 ### Initialization
@@ -387,7 +382,7 @@ For always-on debugging self-checks:
        ./configure --enable-rcu-debug
 
 For fine grained enabling of debugging self-checks, build
-urserspace-rcu with DEBUG_RCU defined and compile dependent
+userspace-rcu with DEBUG_RCU defined and compile dependent
 applications with DEBUG_RCU defined when necessary.
 
 Warning: Enabling this feature result in a performance penalty.
@@ -410,6 +405,20 @@ systems can be disabled with:
 theoretically yielding slightly better performance.
 
 
+### Usage of `--enable-cds-lfht-iter-debug`
+
+By default the library is configured with extra debugging checks for
+lock-free hash table iterator traversal disabled.
+
+Building liburcu with --enable-cds-lfht-iter-debug and rebuilding
+application to match the ABI change allows finding cases where the hash
+table iterator is re-purposed to be used on a different hash table while
+still being used to iterate on a hash table.
+
+This option alters the rculfhash ABI. Make sure to compile both library
+and application with matching configuration.
+
+
 Make targets
 ------------
 
@@ -424,6 +433,33 @@ In addition to the usual `make check` target, Userspace RCU features
   - `make bench`: long (many hours) benchmarks.
 
 
+Known issues
+------------
+
+There is an application vs library compatibility issue between
+applications built using Userspace RCU 0.10 headers linked against
+Userspace RCU 0.11 or 0.12 shared objects. The problem occurs as
+follows:
+
+  - An application executable is built with _LGPL_SOURCE defined, includes
+    any of the Userspace RCU 0.10 urcu flavor headers, and is built
+    without the -fpic compiler option.
+
+  - The Userspace RCU 0.10 library shared objects are updated to 0.11
+    or 0.12 without rebuilding the application.
+
+  - The application will hang, typically when RCU grace period
+    (synchronize_rcu) is invoked.
+
+Some possible work-arounds for this are:
+
+  - Rebuild the application against Userspace RCU 0.11+.
+
+  - Rebuild the application with -fpic.
+
+  - Upgrade Userspace RCU to 0.13+ without installing 0.11 nor 0.12.
+
+
 Contacts
 --------