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
[email protected]
signature.asc
Description: Message signed with OpenPGP
