Re: [PR] fix compiler optimize thread local variable access (brpc)
zcfh commented on PR #2156: URL: https://github.com/apache/brpc/pull/2156#issuecomment-2124600518 > 另外还有一个疑问是，函数 task_runner 和 tls_task_group 不都是在一个编译单元内吗？为什么是开启lto后才会触发这个问题呢。 这个差异找到了。和clang对tls变量访问的选择有关。如果使用-fPIC编译 + 分布式 thinlto ，clang-16之前都会出现这种行为差异，[具体原因](https://discourse.llvm.org/t/how-to-learn-tls-variable-access-using-register-optimized-decisions/78830/12)。 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For additional commands, e-mail: dev-h...@brpc.apache.org
Re: [PR] fix compiler optimize thread local variable access (brpc)
zcfh commented on PR #2156:
URL: https://github.com/apache/brpc/pull/2156#issuecomment-1976430923
目前从clang11 切换 到clang16 遇到了一些新的问题。和 #1776
提到的问题应该是一样的，不过我看**1776对应的代码并没有合入**, 是有做了其他修复吗。
对比了汇编，这样差异在于326-331 行这段代码（version 0.96）
```c++
// Clean tls variables, must be done before changing version_butex
// otherwise another thread just joined this thread may not see side
// effects of destructing tls variables.
KeyTable* kt = tls_bls.keytable;
if (kt != NULL) {
return_keytable(m->attr.keytable_pool, kt);
// After deletion: tls may be set during deletion.
tls_bls.keytable = NULL;
m->local_storage.keytable = NULL; // optional
}
```
clang11 对于 tls_bls 成员变量的读写，每次都会经过一次call。而clang16会在`do`循环外缓存`tls_bls`的地址。
具体汇编差异如下
clang11
``` as
;third_party/brpc-0.9.6/src/bthread/task_group.cpp:325
# KeyTable* kt = tls_bls.keytable;
a9e:66 48 8d 3d 00 00 00data16 lea 0x0(%rip),%rdi# aa6
aa5:00
aa6:66 66 48 e8 00 00 00data16 data16 callq aae
aad:00
aae:48 8b 30mov(%rax),%rsi
third_party/brpc-0.9.6/src/bthread/task_group.cpp:326
ab1:48 85 f6test %rsi,%rsi
ab4:74 28 je ade
...
third_party/brpc-0.9.6/src/bthread/task_group.cpp:329
# tls_bls.keytable = NULL;
abf:66 48 8d 3d 00 00 00data16 lea 0x0(%rip),%rdi# ac7
ac6:00
ac7:66 66 48 e8 00 00 00data16 data16 callq acf
ace:00
acf:48 c7 00 00 00 00 00movq $0x0,(%rax)
```
clang16
```
;third_party/brpc-0.9.6/src/bthread/task_group.cpp:265
838:48 8b 40 30 mov0x30(%rax),%rax
83c:48 85 c0test %rax,%rax
83f:75 df jne820
841:4c 89 65 d0 mov%r12,-0x30(%rbp)
845:66 48 8d 3d 00 00 00data16 lea 0x0(%rip),%rdi# 84d
84c:00
84d:66 66 48 e8 00 00 00data16 data16 callq 855
854:00
855:48 89 c3mov%rax,%rbx # do 循环外保存 tls_bls
的地址到rbx
...
;third_party/brpc-0.9.6/src/bthread/task_group.cpp:325
# KeyTable* kt = tls_bls.keytable;
96e:48 8b 33mov(%rbx),%rsi
;third_party/brpc-0.9.6/src/bthread/task_group.cpp:326
971:48 85 f6test %rsi,%rsi
974:74 18 je 98e
...
;third_party/brpc-0.9.6/src/bthread/task_group.cpp:329
# tls_bls.keytable = NULL;
97f:48 c7 03 00 00 00 00movq $0x0,(%rbx)
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org
For additional commands, e-mail: dev-h...@brpc.apache.org
Re: [PR] fix compiler optimize thread local variable access (brpc)
ehds commented on PR #2156: URL: https://github.com/apache/brpc/pull/2156#issuecomment-1926722893 > 另外还有一个疑问是，函数 task_runner 和 tls_task_group 不都是在一个编译单元内吗？为什么是开启lto后才会触发这个问题呢。 不开启 `lto` 也是会有这个问题的，具体跟编译器的类别、版本以及编译参数等有关。具体的话可以通过 llvm-objdump/objdump 工具把可执行的产物 dump 出来，看下 task_runner 函数里面获取 `tls_task_group` 是否符合预期来进行分析。 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For additional commands, e-mail: dev-h...@brpc.apache.org
Re: [PR] fix compiler optimize thread local variable access (brpc)
zcfh commented on PR #2156: URL: https://github.com/apache/brpc/pull/2156#issuecomment-1926332705 另外还有一个疑问是，函数 task_runner 和 tls_task_group 不都是在一个编译单元内吗？为什么是开启lto后才会触发这个问题呢。 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For additional commands, e-mail: dev-h...@brpc.apache.org
Re: [PR] fix compiler optimize thread local variable access (brpc)
ehds commented on PR #2156:
URL: https://github.com/apache/brpc/pull/2156#issuecomment-1926276260
> 感觉还是 thread_local 读写的问题， 请问下除了这个patch外，后面还有其他关于这个问题的修复吗？ 目前去掉
`src/bthread/task_group.cpp` 的lto后，可以正常工作。
>
> task_runner 循环外的 tls，也加上 BAIDU_GET_VOLATILE_THREAD_LOCAL，后似乎问题不再出现了。
>
> ```
> void TaskGroup::task_runner(intptr_t skip_remained) {
> // NOTE: tls_task_group is volatile since tasks are moved around
> // different groups.
> -TaskGroup* g = tls_task_group;
> +TaskGroup* g = BAIDU_GET_VOLATILE_THREAD_LOCAL(tls_task_group);
> ```
https://github.com/apache/brpc/pull/2248
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org
For additional commands, e-mail: dev-h...@brpc.apache.org
Re: [PR] fix compiler optimize thread local variable access (brpc)
zcfh commented on PR #2156: URL: https://github.com/apache/brpc/pull/2156#issuecomment-1926165119 感觉还是 thread_local 读写的问题， 请问下除了这个patch外，后面还有其他关于这个问题的修复吗？ 目前去掉 `src/bthread/task_group.cpp` 的lto后，可以正常工作。 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For additional commands, e-mail: dev-h...@brpc.apache.org
Re: [PR] fix compiler optimize thread local variable access (brpc)
zcfh commented on PR #2156: URL: https://github.com/apache/brpc/pull/2156#issuecomment-1925685544 目前还没无法构造一个最小示例。 在加上这个commit的修改后，AddressSanitizer 会提示 heap-use-after-free，不过不会显示释放的位置, 使用 `--usercode_in_pthread` 就无法复现这个错误了。 ``` ==31802==ERROR: AddressSanitizer: heap-use-after-free on address 0x614000141808 at pc 0x02bc12f4 bp 0x7fbc7639f820 sp 0x7fbc7639f818 READ of size 8 at 0x614000141808 thread T26 #0 0x2bc12f3 in bthread::KeyTable::get_data(bthread_key_t) const /tmp/third_party/brpc-0.9.6/src/bthread/key.cpp:173:41 #1 0x2bc12f3 in bthread_getspecific /tmp/third_party/brpc-0.9.6/src/bthread/key.cpp:466:20 #2 0x1e26d74 in rpc::brpc::ContextHolderImpl::Get() /tmp/infra/kess_grpc-v1100/src/main/brpc/kess/rpc/brpc/context_holder.h:54:40 #3 0x1e26ba1 in rpc::brpc::KEnvHolder::Get() /tmp/infra/kess_grpc-v1100/src/main/brpc/kess/rpc/brpc/context_holder.h:106:43 #4 0x3d75afe in infra::kenv::Context::Get0(void*) /tmp/infra/kenv/src/kenv/context.cc:92:37 #10 0x28799fc in brpc::policy::ProcessHttpRequest(brpc::InputMessageBase*) /tmp/third_party/brpc-0.9.6/src/brpc/policy/http_rpc_protocol.cpp:1489:21 #11 0x283b8ba in brpc::ProcessInputMessage(void*) /tmp/third_party/brpc-0.9.6/src/brpc/input_messenger.cpp:136:5 #12 0x2bd676e in bthread::TaskGroup::task_runner(long) /tmp/third_party/brpc-0.9.6/src/bthread/task_group.cpp:301:29 #13 0x2b9fd30 in bthread_make_fcontext (/tmp/brpc/brpc-server+0x2b9fd30) 0x614000141808 is located 8 bytes inside of 256-byte region [0x614000141800,0x614000141900) freed by thread T19 here: #0 0x1df750d in operator delete(void*) /llvm/projects/compiler-rt/lib/asan/asan_new_delete.cpp:160:3 previously allocated by thread T26 here: #0 0x1df6ecd in operator new(unsigned long, std::nothrow_t const&) /llvm/projects/compiler-rt/lib/asan/asan_new_delete.cpp:105:3 Thread T26 created by T0 here: #0 0x1db185a in pthread_create /llvm/projects/compiler-rt/lib/asan/asan_interceptors.cpp:214:3 #1 0x2bd1147 in bthread::TaskControl::add_workers(int) /tmp/third_party/brpc-0.9.6/src/bthread/task_control.cpp:218:24 #2 0x2b8afeb in bthread_setconcurrency /tmp/third_party/brpc-0.9.6/src/bthread/bthread.cpp:315:16 #3 0x2aad924 in brpc::Server::StartInternal(in_addr const&, brpc::PortRange const&, brpc::ServerOptions const*) /tmp/third_party/brpc-0.9.6/src/brpc/server.cpp:914:9 #4 0x2ab4967 in brpc::Server::Start(butil::EndPoint const&, brpc::ServerOptions const*) /tmp/third_party/brpc-0.9.6/src/brpc/server.cpp:1060:12 #5 0x2ab4f3e in brpc::Server::Start(int, brpc::ServerOptions const*) /tmp/third_party/brpc-0.9.6/src/brpc/server.cpp:1079:12 ... #11 0x1df9a08 in main /tmp/brpc/src/server.cc:46:30 #12 0x7fbc9b405554 in __libc_start_main (/lib64/libc.so.6+0x22554) Thread T19 created by T0 here: #0 0x1db185a in pthread_create /llvm/projects/compiler-rt/lib/asan/asan_interceptors.cpp:214:3 #1 0x2bd0a9d in bthread::TaskControl::init(int) /tmp/third_party/brpc-0.9.6/src/bthread/task_control.cpp:184:24 #2 0x2b8c025 in bthread::get_or_new_task_control() /tmp/third_party/brpc-0.9.6/src/bthread/bthread.cpp:94:12 #3 0x2b8a7dd in bthread::start_from_non_worker(unsigned long*, bthread_attr_t const*, void* (*)(void*), void*) /tmp/third_party/brpc-0.9.6/src/bthread/bthread.cpp:131:22 #4 0x2b8a7dd in bthread_start_background /tmp/third_party/brpc-0.9.6/src/bthread/bthread.cpp:198:12 #5 0x28160a2 in brpc::GlobalInitializeOrDieImpl() /tmp/third_party/brpc-0.9.6/src/brpc/global.cpp:605:27 #6 0x7fbc9b9cd20a in __pthread_once_slow (/lib64/libpthread.so.0+0x620a) SUMMARY: AddressSanitizer: heap-use-after-free /tmp/third_party/brpc-0.9.6/src/bthread/key.cpp:173:41 in bthread::KeyTable::get_data(bthread_key_t) const Shadow bytes around the buggy address: 0x0c28800202b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c28800202c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c28800202d0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 0x0c28800202e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c28800202f0: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa =>0x0c2880020300: fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c2880020310: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c2880020320: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2880020330: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2880020340: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2880020350: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1
Re: [PR] fix compiler optimize thread local variable access (brpc)
zcfh commented on PR #2156: URL: https://github.com/apache/brpc/pull/2156#issuecomment-1925685023 目前还没无法构造一个最小示例。 在加上这个commit的修改后，AddressSanitizer 会提示 heap-use-after-free，不过不会显示释放的位置, 使用 `--usercode_in_pthread` 就无法复现这个错误了。 ``` ==31802==ERROR: AddressSanitizer: heap-use-after-free on address 0x614000141808 at pc 0x02bc12f4 bp 0x7fbc7639f820 sp 0x7fbc7639f818 READ of size 8 at 0x614000141808 thread T26 #0 0x2bc12f3 in bthread::KeyTable::get_data(bthread_key_t) const /tmp/third_party/brpc-0.9.6/src/bthread/key.cpp:173:41 #1 0x2bc12f3 in bthread_getspecific /tmp/third_party/brpc-0.9.6/src/bthread/key.cpp:466:20 #2 0x1e26d74 in rpc::brpc::ContextHolderImpl::Get() /tmp/infra/kess_grpc-v1100/src/main/brpc/kess/rpc/brpc/context_holder.h:54:40 #3 0x1e26ba1 in rpc::brpc::KEnvHolder::Get() /tmp/infra/kess_grpc-v1100/src/main/brpc/kess/rpc/brpc/context_holder.h:106:43 #4 0x3d75afe in infra::kenv::Context::Get0(void*) /tmp/infra/kenv/src/kenv/context.cc:92:37 #10 0x28799fc in brpc::policy::ProcessHttpRequest(brpc::InputMessageBase*) /tmp/third_party/brpc-0.9.6/src/brpc/policy/http_rpc_protocol.cpp:1489:21 #11 0x283b8ba in brpc::ProcessInputMessage(void*) /tmp/third_party/brpc-0.9.6/src/brpc/input_messenger.cpp:136:5 #12 0x2bd676e in bthread::TaskGroup::task_runner(long) /tmp/third_party/brpc-0.9.6/src/bthread/task_group.cpp:301:29 #13 0x2b9fd30 in bthread_make_fcontext (/tmp/brpc/brpc-server+0x2b9fd30) 0x614000141808 is located 8 bytes inside of 256-byte region [0x614000141800,0x614000141900) freed by thread T19 here: #0 0x1df750d in operator delete(void*) /home/syslab/guyin/Compile_upgrade/Clang11/clang-11.1.0-dev/src_tree/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cpp:160:3 previously allocated by thread T26 here: #0 0x1df6ecd in operator new(unsigned long, std::nothrow_t const&) /home/syslab/guyin/Compile_upgrade/Clang11/clang-11.1.0-dev/src_tree/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cpp:105:3 Thread T26 created by T0 here: #0 0x1db185a in pthread_create /home/syslab/guyin/Compile_upgrade/Clang11/clang-11.1.0-dev/src_tree/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cpp:214:3 #1 0x2bd1147 in bthread::TaskControl::add_workers(int) /tmp/third_party/brpc-0.9.6/src/bthread/task_control.cpp:218:24 #2 0x2b8afeb in bthread_setconcurrency /tmp/third_party/brpc-0.9.6/src/bthread/bthread.cpp:315:16 #3 0x2aad924 in brpc::Server::StartInternal(in_addr const&, brpc::PortRange const&, brpc::ServerOptions const*) /tmp/third_party/brpc-0.9.6/src/brpc/server.cpp:914:9 #4 0x2ab4967 in brpc::Server::Start(butil::EndPoint const&, brpc::ServerOptions const*) /tmp/third_party/brpc-0.9.6/src/brpc/server.cpp:1060:12 #5 0x2ab4f3e in brpc::Server::Start(int, brpc::ServerOptions const*) /tmp/third_party/brpc-0.9.6/src/brpc/server.cpp:1079:12 ... #11 0x1df9a08 in main /tmp/brpc/src/server.cc:46:30 #12 0x7fbc9b405554 in __libc_start_main (/lib64/libc.so.6+0x22554) Thread T19 created by T0 here: #0 0x1db185a in pthread_create /home/syslab/guyin/Compile_upgrade/Clang11/clang-11.1.0-dev/src_tree/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cpp:214:3 #1 0x2bd0a9d in bthread::TaskControl::init(int) /tmp/third_party/brpc-0.9.6/src/bthread/task_control.cpp:184:24 #2 0x2b8c025 in bthread::get_or_new_task_control() /tmp/third_party/brpc-0.9.6/src/bthread/bthread.cpp:94:12 #3 0x2b8a7dd in bthread::start_from_non_worker(unsigned long*, bthread_attr_t const*, void* (*)(void*), void*) /tmp/third_party/brpc-0.9.6/src/bthread/bthread.cpp:131:22 #4 0x2b8a7dd in bthread_start_background /tmp/third_party/brpc-0.9.6/src/bthread/bthread.cpp:198:12 #5 0x28160a2 in brpc::GlobalInitializeOrDieImpl() /tmp/third_party/brpc-0.9.6/src/brpc/global.cpp:605:27 #6 0x7fbc9b9cd20a in __pthread_once_slow (/lib64/libpthread.so.0+0x620a) SUMMARY: AddressSanitizer: heap-use-after-free /tmp/third_party/brpc-0.9.6/src/bthread/key.cpp:173:41 in bthread::KeyTable::get_data(bthread_key_t) const Shadow bytes around the buggy address: 0x0c28800202b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c28800202c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c28800202d0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 0x0c28800202e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c28800202f0: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa =>0x0c2880020300: fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c2880020310: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c2880020320: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2880020330: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2880020340: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2880020350: fa fa fa fa fa fa fa fa fa
Re: [PR] fix compiler optimize thread local variable access (brpc)
ehds commented on PR #2156: URL: https://github.com/apache/brpc/pull/2156#issuecomment-1923713768 > > > 加上这个patch后，稳定出现第一种错误，是 socket.cpp 也有类似的问题吗？ > > > > > > 是在哪个平台上出现呢？arm 还是 x86 ？ 可以贴下 PoC 代码。 > > x86, `(defined(__aarch64__) || defined(__arm64__))`，去掉后不再core在前面提到的两个位置。 > > core在了其他地方，找了下调用栈，有地方是这么用的 `static thread_local Object obj;`。是用了btread的地方，只要用到 thread_local 的都需要做类似的变更吗？ > > 我之前没用过brpc，如何能够构造一个，问题里提到到示例呢？ 如果使用 thread_local 变量时，前后两次该变量的中间阶段发生了 bthread 的切换（由于 `start_urgent` 或者 `butex` 等待，`bthread_usleep` 等操作），那么 `thread_local` 变量就可能不是之前的对象了，这个和 bthread 的设计相关，因为 bthread 运行周期可以被调度到不同的 pthread 上执行，所以前后两次所在的 pthread 上下文已经变化，其 thread_local 变量也就变化了。 具体见：https://brpc.apache.org/docs/bthread/thread-local/#thread-local%E9%97%AE%E9%A2%98 > 是用了btread的地方，只要用到 thread_local 的都需要做类似的变更吗？ 这个得分情况：如果想要在 bthread 中使用类似 "thread_local" 的行为，即无论 bthread 被调度到哪，都获得相同的 thread_local 值，建议使用 `bthread_local` https://brpc.apache.org/zh/docs/server/basics/#bthread-local 如果代码就是想要获得当前被调度运行的 pthread 线程的 `thread_local` 变量(例如 brpc 中的 `tls_task_group `），那么就建议如果会出现上述导致 bthread 切换的行为，那么建议使用这个宏，避免编译器的优化。 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For additional commands, e-mail: dev-h...@brpc.apache.org
Re: [PR] fix compiler optimize thread local variable access (brpc)
zcfh commented on PR #2156: URL: https://github.com/apache/brpc/pull/2156#issuecomment-1923616331 > > 加上这个patch后，稳定出现第一种错误，是 socket.cpp 也有类似的问题吗？ > > 是在哪个平台上出现呢？arm 还是 x86 ？ 可以贴下 PoC 代码。 x86, `(defined(__aarch64__) || defined(__arm64__))`，去掉后不再core在前面提到的两个位置。 core在了其他地方，找了下调用栈，有地方是这么用到 `static thread_local Object obj;`的。是用了btread的地方，只要用到 thread_local 的都需要做类似的变更吗？ 我之前没用过brpc，如何能够构造一个，问题里提到到示例呢？ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For additional commands, e-mail: dev-h...@brpc.apache.org
Re: [PR] fix compiler optimize thread local variable access (brpc)
ehds commented on PR #2156: URL: https://github.com/apache/brpc/pull/2156#issuecomment-1923274012 > 加上这个patch后，稳定出现第一种错误，是 socket.cpp 也有类似的问题吗？ 是在哪个平台上出现呢？arm 还是 x86 ？ 可以贴下 PoC 代码。 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For additional commands, e-mail: dev-h...@brpc.apache.org
Re: [PR] fix compiler optimize thread local variable access (brpc)
zcfh commented on PR #2156: URL: https://github.com/apache/brpc/pull/2156#issuecomment-1922778151 遇到了和 [iss 1860](https://github.com/apache/brpc/issues/1860) 一样的问题。 项目依赖 brpc-0.9.6， 使用clang-11 加上thinlto构建项目，可能出现两种错误 ``` // 第一种 socket.cpp:1070, IsWriteComplete] Check failed: p != NULL // 第二种 task_group.cpp:623, sched_to] bthread=4294967296 sched_to itself! ``` brpc单独关闭thinlto后，和1860 一样，会出现第二种错误，但是还是能够运行。 加上这个patch后，稳定出现第一种错误，是 socket.cpp 也有类似的问题吗？ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For additional commands, e-mail: dev-h...@brpc.apache.org
Re: [PR] fix compiler optimize thread local variable access (brpc)
wwbmmm merged PR #2156: URL: https://github.com/apache/brpc/pull/2156 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For additional commands, e-mail: dev-h...@brpc.apache.org
Re: [PR] fix compiler optimize thread local variable access (brpc)
wwbmmm commented on PR #2156: URL: https://github.com/apache/brpc/pull/2156#issuecomment-1463638776 LGTM -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For additional commands, e-mail: dev-h...@brpc.apache.org
Re: [PR] fix compiler optimize thread local variable access (brpc)
ehds commented on code in PR #2156: URL: https://github.com/apache/brpc/pull/2156#discussion_r1131964082 ## CMakeLists.txt: ## @@ -150,6 +150,11 @@ if(CMAKE_CXX_COMPILER_ID STREQUAL "GNU") endif() endif() +if(CMAKE_CXX_COMPILER_ID MATCHES "(AppleClang)|(Clang)" AND CMAKE_SYSTEM_PROCESSOR MATCHES "(aarch64)|(arm64)") Review Comment: done -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For additional commands, e-mail: dev-h...@brpc.apache.org
Re: [PR] fix compiler optimize thread local variable access (brpc)
wwbmmm commented on code in PR #2156: URL: https://github.com/apache/brpc/pull/2156#discussion_r1131953069 ## CMakeLists.txt: ## @@ -150,6 +150,11 @@ if(CMAKE_CXX_COMPILER_ID STREQUAL "GNU") endif() endif() +if(CMAKE_CXX_COMPILER_ID MATCHES "(AppleClang)|(Clang)" AND CMAKE_SYSTEM_PROCESSOR MATCHES "(aarch64)|(arm64)") Review Comment: 在这里判断的话只对cmake生效，我们还有make和bazel两种编译方式 是不是在头文件里进行判断，普适性更好一些 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For additional commands, e-mail: dev-h...@brpc.apache.org
Re: [PR] fix compiler optimize thread local variable access (brpc)
ehds commented on PR #2156: URL: https://github.com/apache/brpc/pull/2156#issuecomment-1463229810 > > 1. 新增 `NOT_ALLOW_OPTIMIZE_THREAD_LOCAL_ACCESS` 用于控制是否允许编译器优化 > > 能否自动根据当前编译器和平台来决定是否开启这个宏？ done, 根据issue的反馈信息，目前仅针对 Clang/AppleClang 并且是 ARM/AArch 架构平台关闭优化。 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For additional commands, e-mail: dev-h...@brpc.apache.org
Re: [PR] fix compiler optimize thread local variable access (brpc)
wwbmmm commented on PR #2156: URL: https://github.com/apache/brpc/pull/2156#issuecomment-1463116051 > 1. 新增 `NOT_ALLOW_OPTIMIZE_THREAD_LOCAL_ACCESS` 用于控制是否允许编译器优化 能否自动根据当前编译器和平台来决定是否开启这个宏？ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For additional commands, e-mail: dev-h...@brpc.apache.org
