pkubaj opened a new pull request, #3696:
URL: https://github.com/apache/brpc/pull/3696
Issue Number: #2697
Problem Summary: brpc does not build on 64-bit PowerPC.
`butil/build_config.h`
and `butil/atomicops.h` have no entry for the architecture, `butil/time.h`
fails with "unsupported arch" in `clock_cycles()`, and bthread has no context
switch for it.
### What is changed and the side effects?
Changed:
- `build_config.h`: `ARCH_CPU_PPC64_FAMILY` / `ARCH_CPU_PPC64`, endianness
from `__BYTE_ORDER__`.
- `atomicops`: use `atomicops_internals_gcc.h`, which gains the `Atomic64`
operations it was missing (the builtins already handle 64-bit values).
- `time.h`: `clock_cycles()` reads the time base with `mftb`.
- `processor.h`: `cpu_relax()` lowers the SMT thread priority briefly
(`or 1,1,1` / `or 2,2,2`), as the Linux kernel's `cpu_relax()` does.
- `debugger_posix.cc`: `trap` as the break instruction.
- `bthread/context.{h,cpp}`: ELFv2 implementation of
`bthread_jump_fcontext` / `bthread_make_fcontext`, derived from
boost.context's `jump_ppc64_sysv_elf_gas.S` / `make_ppc64_sysv_elf_gas.S`.
The frame holds r14-r31, CR, LR, f14-f31, FPSCR and, when AltiVec is
enabled, v20-v31 and VRSAVE; all of these are non-volatile in the ELFv2
ABI, so a switch that dropped them would corrupt values the compiler keeps
live across the call (the patch attached to #2697 saves only the FPRs and
does not restore FPSCR). A new context starts with the current CR, FPSCR
and VRSAVE.
- `mongo_head.h`: `ARCH_CPU_LITTLE_ENDIAN` is only defined on little-endian
targets, so the byte-swap is decided by the preprocessor.
Side effects:
- Only the ELFv2 ABI is supported: ppc64le everywhere, big-endian ppc64 on
FreeBSD and musl. ELFv1 (glibc ppc64 big-endian) keeps failing as before.
- No change for any other architecture; every edit is behind
`__powerpc64__` / `ARCH_CPU_PPC64_FAMILY` / the new platform macro.
### Tested
FreeBSD 15.1 powerpc64le (POWER9, clang 19, protobuf 5.29, system
googletest 1.16):
- Library, tools and `BUILD_UNIT_TESTS=ON` build. 18 of the 20
`bthread_*unittest` binaries pass completely: butex, butex_multi_tag, cond,
cond_bug, countdown_event, execution_queue, futex, id, key, list, once,
ping_pong, rwlock, sched_yield, semaphore, timer_thread,
work_stealing_queue and bthread_unittest.
- `bthread_mutex_unittest`: every test passes when run on its own
(`--gtest_filter`), but the whole binary hangs in
`MutexTest.mix_thread_types` after the performance tests (killed after
5 min). `bthread_setconcurrency_unittest`: `min_concurrency` and
`concurrency_by_tag` fail their worker-count assertions (250 expected,
201 seen; "Invalid concurrency_by_tag=1"). Both look like scheduler
accounting / test-order issues rather than the context switch, which the
passing butex/cond/ping_pong/work-stealing tests exercise heavily; I could
not compare against an amd64 FreeBSD run.
- `bthread_dispatcher_unittest` and `bthread_fd_unittest` do not compile on
non-Linux hosts (undeclared `n`, `wait_rc`, `epfd`), independent of this
change.
- Note for the test build: `test/CMakeLists.txt` calls `use_cxx11()`, which
pins the debug butil/bvar copies to C++11 while protobuf 5 / abseil need
C++14+ (the library itself gets C++17 from the top-level file); I
commented that call out for the test run. That is a separate issue.
- A standalone register-pinned stress test of the new context switch (loads
distinct patterns into f14-f31 and v20-v31 on each side of the switch,
sets different FPSCR rounding modes per context, 300 000 round trips at
-O2 and 100 000 at -O0) shows no register or FPSCR corruption on
powerpc64le or big-endian powerpc64.
- The library also builds on big-endian FreeBSD powerpc64 (ELFv2).
Written with the help of Claude Code.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
