Hi all, I’ve recently got rid of the old Gentoo that still targets sparc32plus on my T5120 and switched to Debian sid for sparc64. Unfortunately, haproxy doesn’t work properly: SIGBUS happen here and there. Tweaking unrelated configuration options (such as load-balance or removing servers in backends) would sometimes get pass the problem when testing the configuration file, but will then result in SIGBUS when haproxy is up and running.
I’ve tried the following operating systems: - Debian sid sparc64 - OpenBSD 6.3 sparc64 On Solaris 11.3, the situation is a little bit close to what’s happening on Gentoo: a sparc32plus binary is generated, and only 4byte load / store instructions are used, so alignment isn’t an issue. I am not able to get it working though; segfaults are happening, and I’m looking into it. Will sum up what I found in a following email. I tracked into the issue a little bit further, and discovered that it was due to unaligned memory access (and there’re plenty of them). Seems like the current codebase assumes a 4-byte alignment, yet on SPARC64, we have 8 bytes for a pointer (long). Take the first SIGBUS as an example: ebtree/eb32tree.h:347: *up_ptr = new_left; Look into the assembly layout in GDB and we’ll find that we’re storing using “six”, which is the 8byte store instruction: <eb32_insert+612> stx %i1, [ %o4 ] And we’ll find that %o4 is not aligned properly by 8bytes if we inspect the register. (gdb) i reg o4 o4 0x7e90e77e84 Continuing here will result in a SIGBUS. Possible solutions include aligning the memory properly, use an OS trap, break up 8byte load/store instructions on misalign-prone addresses (via compiler), maybe more. After my last-week effort all the ones except correcting code to align memory properly seem impossible to achieve. However, I’m not familiar with how haproxy deals with memory alignment, so I’m asking for help here. Thanks in advance, — Pengcheng Xu i...@jsteward.moe
signature.asc
Description: Message signed with OpenPGP