[Various] HAVE_FAST_UNALIGNED_ACCESS

[Robert Pluim]

Po Lu is still having problems getting mail delivered to emacs-devel

> --- Begin Message ---
>
>
>
> Subject: 
>
> Topics
>
>
>
>
> Topics:
>    Re: HAVE_FAST_UNALIGNED_ACCESS
>    Re: HAVE_FAST_UNALIGNED_ACCESS
>    Re: HAVE_FAST_UNALIGNED_ACCESS
>
> --- End Message ---

--- Begin Message --- Subject: Re: HAVE_FAST_UNALIGNED_ACCESS Date: Thu, 30 Mar 2023 17:08:16 +0530

On Thu, 2023-03-30 at 11:34 +0200, Robert Pluim wrote:
> Instead, HAVE_FAST_UNALIGNED_ACCESS and UNALIGNED_LOAD_SIZE should be
> removed and memcpy used instead:
> 
>   word_t a, c;
> 
>   memcpy (&a, w1 + b / ws, sizeof a);
>   memcpy (&c, w2 + b / ws, sizeof c);
> 

I had recently made a few modifications to this on master. There,
Fstring_lessp in uses the macro UNALIGNED_LOAD_SIZE instead, which is
defined to __sanitizer_unaligned_loadXX in lisp.h if:

* We're building with AddressSaniziter,
* <sanitizer/common_interface_defs.h> is available, and
* USE_SANITIZER_UNALIGNED_LOAD is defined.

> I would like to install such a change on emacs-29.  Emacs currently
> crashes when built with various compilers performing pointer
> alignment
> checks.

Instead of removing the code entirely, you could try modifying the
macro definition by getting rid of the AddressSanitizer ifdef, and
building with USE_SANITIZER_UNALIGNED_LOAD.  In theory, this should
make the load not crash with other sanitizers as well. If that works, I
imagine that would be a slightly more acceptable change to install into
emacs-29.

Best,
Vibhav
-- 
Vibhav Pant
vibhavp@gmail.com
GPG: 7ED1 D48C 513C A024 BE3A  785F E3FB 28CB 6AB5 9598

signature.asc
Description: This is a digitally signed message part

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: HAVE_FAST_UNALIGNED_ACCESS
>
>
>
>
> Date: 
>
> Thu, 30 Mar 2023 19:15:30 +0800
>
>
>
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > This is incorrect.  There's nothing undefined about x86 unaligned
> > accesses.  C standards can regard this as UB, but we are using
> > machine-specific knowledge here (and Emacs cannot be built with a
> > strict adherence to C standards anyway).
>
> GCC defines this as undefined behavior:
>
>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93031
>
> and it causes crashes in real code, as explained in the bug report.
>
> >> Instead, HAVE_FAST_UNALIGNED_ACCESS and UNALIGNED_LOAD_SIZE should be
> >> removed and memcpy used instead:
> >> 
> >>   word_t a, c;
> >> 
> >>   memcpy (&a, w1 + b / ws, sizeof a);
> >>   memcpy (&c, w2 + b / ws, sizeof c);
> >> 
> >> doing so will make the compiler itself generate the right sequence of
> >> instructions for performing unaligned accesses, normally with only a few
> >> cycles penalty.
> >
> > We don't want that penalty here, that's all.
>
> There is no penalty.  All it avoids is a crash.
>
> > Details, please.  Which compilers, on what platforms, for what target
> > architectures, etc.  Unconditionally removing the fast copy there is a
> > non-starter.
>
> GCC.  On x86_64, with -fsanitize=undefined.
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: HAVE_FAST_UNALIGNED_ACCESS
>
>
>
>
> Date: 
>
> Thu, 30 Mar 2023 19:12:48 +0800
>
>
>
>
> Mattias Engdegård <mattiase@acm.org> writes:
>
> > That's not necessarily a problem; we have plenty of formally undefined
> > behaviour. What's important is whether we can be confident that it
> > works.
>
> You can't be confident this will work, at least not with GCC.  See what
> the GCC developers say about this undefined behavior:
>
>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93031
>
> specifically:
>
>   It's still UB.  Note that GCC has for a _long_ time made this
>   assumption - just the places we take advantage of it have grown.
>
> and also, I've seen a large number of program crashes from GCC
> generating x86 instructions that assume alignment, such as movqda, when
> the programmer apparently knew that x86 does not have strict alignment
> requirements.
>
> > No, this isn't something we should be doing at all unless the platform
> > allows fast unaligned access.
>
> All modern processors do have ``fast unaligned access'', but you have to
> tell the compiler that the access is unaligned.  Hence memcpy.
>
> Compilers will then generate the right sequence of instructions to
> efficiently perform the unaligned access, such as a pair of load-word
> left and load-word right instructions on MIPS processors.
>
> > Which compilers, exactly?
>
> GCC, with -fsanitize=undefined.
>
> P.S. would you please quote the entire message when replying, to make
> sure it gets recorded on the list?
>
>
> --- End Message ---
Robert
--