On Tue, Nov 14, 2023 at 12:50 AM Jeffrey Walton <noloa...@gmail.com> wrote: > > On Mon, Nov 13, 2023 at 10:37 PM Bruno Haible <br...@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
