Add required flags to example Makefile #18
Conversation
examples/Makefile
Outdated
| @@ -1,6 +1,6 @@ | |||
| all: | |||
| $(CC) -Wall -o rmw_example rmw_example.c -pthread -lm | |||
| $(CC) -Wall -o rmw_example_aba rmw_example_aba.c -pthread -lm -mcx16 | |||
| $(CC) -Wall -o rmw_example_aba rmw_example_aba.c -pthread -lm -mcx16 -latomic | |||
There was a problem hiding this comment.
If -std=gnu11 or -std=c11 is specified, no more flag should be required.
There was a problem hiding this comment.
My GCC version is 13.3.0, which should support C11.
I suspect the issue is caused by the use of the -mcx16 flag.
Other builds that use atomic operations but don't require -mcx16 work fine without linking against -latomic.
There was a problem hiding this comment.
Check recent GCC bugzilla activities to narrow down.
There was a problem hiding this comment.
I came across GCC Bug 104688, which is still open. Based on the current discussion there, here's my understanding:
On x86 architecture, major CPU vendors like Intel, AMD, and Zhaoxin have all provided guarantees that 16-byte atomic loads and stores (e.g., using VMOVDQA or VMOVDQU) are safe and truly atomic, provided that the memory is write-back (WB) type and 16-byte aligned. GCC’s libatomic leverages these guarantees to support atomic operations on __int128 and other 16-byte types.
Currently, these operations are implemented via function calls in libatomic. So when using -mcx16, it's still necessary to explicitly link with -latomic if the program uses 16-byte atomic operations, otherwise compilation or linking might fail.
There are plans to inline these atomic operations in the future to avoid function calls altogether — which is one reason why the bug is not yet closed — but there’s no clear timeline for when that will be fully supported.
Given that, I think it still makes sense to explicitly link -latomic for now to ensure that files like rmw_example_aba.c, which depend on 16-byte RMW operations, compile and run correctly across most platforms.
Bug link:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
There was a problem hiding this comment.
Currently, these operations are implemented via function calls in libatomic. So when using -mcx16, it's still necessary to explicitly link with -latomic if the program uses 16-byte atomic operations, otherwise compilation or linking might fail.
Great. Let's improve the documentation.
There was a problem hiding this comment.
Just to confirm — are you suggesting updating the README.md, or adding a comment in rmw_example_aba.c?
There was a problem hiding this comment.
Just to confirm — are you suggesting updating the README.md, or adding a comment in rmw_example_aba.c?
Add the notice in the footnote of LaTeX document.
There was a problem hiding this comment.
I’ve rebased the previous commit that modified the Makefile. The change is now moved into a footnote in the LaTeX document, as suggested.
The ABA example relies on 16-byte atomic compare-and-swap operations, which require the `-mcx16` compiler flag on x86-64 to enable the corresponding instructions. However, due to current limitations in GCC, 16-byte atomic operations (e.g., `__atomic_load_16` and `__atomic_compare_exchange_16`) are implemented via calls to `libatomic` on many platforms. This results in linker errors unless `-latomic` is explicitly added. To avoid confusion and ensure portability, this patch adds a footnote to the LaTeX document explaining that `-latomic` must be linked when using `-mcx16`. For more details, see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
Page 12 refers to `thread_pool_destroy`, but the actual function name used in the example code is `tpool_destroy`. This commit corrects the discrepancy to avoid confusion.
|
Thank @weiso131 for contributing! |
The original Makefile fails to compile rmw_example_aba.c with the following error:
/usr/bin/ld: /tmp/ccKy48VO.o: in function
worker': rmw_example_aba.c:(.text+0x158): undefined reference to__atomic_load_16'/usr/bin/ld: rmw_example_aba.c:(.text+0x204): undefined reference to
`__atomic_compare_exchange_16'
collect2: error: ld returned 1 exit status
According to the GCC documentation:
https://gcc.gnu.org/onlinedocs/libstdc++/manual/ext_concurrency_impl.html
__atomic builtins are not guaranteed to be fully implemented on all platforms. When using the -mcx16 flag, linking may fail on some systems unless -latomic is explicitly added to the linker flags.