On 2022/8/22 19:58, Willy Tarreau wrote:
On Mon, Aug 22, 2022 at 07:43:18PM +0800, Qu Wenruo wrote:
Tried to compile gcc10 from AUR, which failed to compile.
Anyway, thanks to the advice from Willy, I got the pre-built crosstool
(gcc 7.5) set up, with some small tweaks like disabling
CONFIG_RANDOMIZE_BASE to workaround the RELOCS failure, it at least
compiles for v4.14.0.
Although there is still warning from test_gen_len:
Warning: ffffffff818158cc: 0f ff e9 ud0 %ecx,%ebp
Warning: objdump says 3 bytes, but insn_get_length() says 2
Warning: arch/x86/tools/test_get_len found difference at
<cpu_idle_poll>:ffffffff818159b0
Strange, sounds like a binutils issue though I could be wrong.
I'm using CROSS_COMPILE= option, which should cover the objdump from the
prebuilt "x86_64-linux-objdump" from that precompiled 7.5 crosstool.
And unfortunately v4.14 still fails to boot, even with GCC 7.5, which
provides an almost perfect (except above wanrings) build.
I also tried to reduce the CPUid, from host-passthru to qemu64, and
rebuild, no change (same test_get_len wanrings, same boot failure).
No clue at all now, would try older debian in a VM then.
I suggest that instead of switching distros you should rather first
try 4.14.0 to verify if there was a regression affecting your system.
Already tried, the v4.14 above really means v4.14.0 (aka v4.14 tag
directly from upstream, not from stable).
And the latest v4.14.290 can not boot neither, even rebuilt using that
toolchain.
And if so, then a bisect will certainly be welcome. If it still does
not work, then maybe a different distro could help, though I doubt it.
Will try debian for now, or even try some older hardware if I could find...
Thanks,
Qu
Willy
