Wu Xiaotian

> @whhe @LINxiansheng > > 使用 `cmake -DCMAKE_BUILD_TYPE=Debug ...` 可正常编译出 `observer`；而使用`cmake -DCMAKE_BUILD_TYPE=Release ...` 编译时，在最后链接时会报错如下： > > ``` > [100%] Linking CXX executable observer > cd /home/yetist/checkout/04-loongarch/oceanbase/build/src/observer && /usr/bin/cmake -E cmake_link_script...

我是希望这个分支，至少在x86上可以做到 gcc/clang、release/debug的4种组合都能正常编译出来，然后再拆分补丁，分别创建不同的PR进行合并，希望社区有人能帮忙研究一下这个问题。

本分支在 x86 linux 上最新编译测试情况如下： toolchain | debug | release | ----------- |-------|---------| clang + ld | ✅ | ✅ | clang + lld | ✅ | ✅ | gcc +...

这个热心老外为 libffcall 增加的 LoongArch 架构[补丁](https://git.savannah.gnu.org/cgit/libffcall.git/commit/?id=600d713cd18f09a698f937ff6c2cead41036e3da)，把我给坑了一下，因为他写出了 `__loongarch64__` 这个宏。 https://git.savannah.gnu.org/cgit/libffcall.git/tree/trampoline/trampoline.c#n333 ``` #if defined(__loongarch64__) #define TRAMP_LENGTH 48 #define TRAMP_ALIGN 8 #endif ``` https://git.savannah.gnu.org/cgit/libffcall.git/tree/trampoline/trampoline.c#n1700 ``` #if defined(__loongarch64__) /* Use the GCC built-in. It expands...

这个看起来比较实用。 可否将卷一涉及的指令都按此规范列出来？谢谢。

> ...，以实现新世界对旧世界闭源软件的兼容。 这种兼容预期是到啥程度？新世界内核可以 chroot 运行旧世界用户态？

> > 这种兼容预期是到啥程度？新世界内核可以 chroot 运行旧世界用户态？ > > 应该可以直接运行，在新世界的系统上， 直接运行基于旧世界打造的闭源程序，比如wps等 这个很有难度： 1. 进上游的glibc，对内核的最低要求会写成5.16+(以首个支持LA的上游内核版本为准)。 2. 进上游的glibc，对于库符号版本，会写成2.34+(以首个支持LA的上游glibc版本为准)，而旧世界是2.27。这会导致旧世界库符号版本问题，就是找不到符号。 3. ld.so的路径变化，这个算是最容易解决的。 4. 上面提到的 NSIG、struct sigcontext 等问题。

The results of `make check`: ``` Regression Test Summary tests run: 4693 tests skipped: 121 tests passed: 4693 tests failed: 0 tests errored: 0 ``` The results of `(cd tests;...

After updating the kernel, the tests passed: ``` Regression Test Summary tests run: 4693 tests skipped: 121 tests passed: 4693 tests failed: 0 tests errored: 0 ============================================================ PASS: regression =============...

> > @yetist, just to be clear - are these results from running the tests on loongarch? Yes.