Re: obstack module has alignment issues on sparc? (Re: set_labels_identifiers_target -fsanitize=undefined error)

[Jeffrey Walton]

On Mon, Nov 13, 2023 at 10:37 PM Bruno Haible <bruno@clisp.org> wrote:
>
> Sam James wrote:
> > It appears that the obstack gnulib module is the culprit.
>
> When I compile texinfo-7.1 in such a way that is uses the obstack facility
> from glibc (via 'gl_cv_func_obstack=yes ../configure ...'), I see the same
> bus error as in a build where the obstack facility comes from gnulib.
>
> Therefore, if it is a bug in gnulib, it is also a bug in glibc.
>
> But since obstack_alignment_mask is explicitly documented [1] as a means to
> change the alignment, I wonder whether it is a bug at all?
>
> [1] also says: "By default, this boundary is aligned so that the object can
> hold any type of data." Needs to be investigated in more depth...

On SPARC, 64-bit words can be loaded and saved through one of two
instructions. The first version is optimized, the second version is
not. The optimized version is faster, but the 64-bit words have to be
aligned to 8-byte boundaries. I.e., naturally aligned.

If you are performing unaligned loads of 64-bit words, then you have
to specify the compiler option -xmemalign=4i. -xmemalign=4i will
generate the inefficient load, but it will avoid the SIGBUS.

When using the default toolchain settings, -xmemalign=8s is used,
which causes the toolchain to use the optimized loads. I think that is
what is generating the UBsan finding "runtime error: member access
within misaligned address ... which requires 8 byte alignment."

Also see "3.4.151 –xmemalign[=<a><b>]",
<https://docs.oracle.com/cd/E37069_01/html/E37076/aevkc.html>, in the
Solaris manual.

> [1] 
> https://www.gnu.org/software/libc/manual/html_node/Obstacks-Data-Alignment.html

Jeff