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

[Jeffrey Walton]

On Tue, Nov 14, 2023 at 12:50 AM Jeffrey Walton <noloader@gmail.com> wrote:
>
> 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

This may be a better reference. It is from the C User Guide:
<https://docs.oracle.com/cd/E24457_01/html/E21990/bjapr.html#bjavc>.

Jeff