[Various] HAVE_FAST_UNALIGNED_ACCESS

[Various] HAVE_FAST_UNALIGNED_ACCESS

[Robert Pluim]

[-- Attachment #1: Type: text/plain, Size: 70 bytes --]

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


[-- Attachment #2.1: Type: message/rfc822, Size: 170 bytes --]

Subject: Topics

Topics:
   Re: HAVE_FAST_UNALIGNED_ACCESS
   Re: HAVE_FAST_UNALIGNED_ACCESS
   Re: HAVE_FAST_UNALIGNED_ACCESS

[-- Attachment #2.2: Type: message/rfc822, Size: 2603 bytes --]

[-- Attachment #2.2.1.1: Type: text/plain, Size: 1256 bytes --]

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

[-- Attachment #2.2.1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2.3: Type: message/rfc822, Size: 1490 bytes --]

From: Po Lu <luangruo@yahoo.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Robert Pluim <rpluim@gmail.com>,  emacs-devel@gnu.org
Subject: Re: HAVE_FAST_UNALIGNED_ACCESS
Date: Thu, 30 Mar 2023 19:15:30 +0800
Message-ID: <87bkkav6b1.fsf@yahoo.com>

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.


[-- Attachment #2.4: Type: message/rfc822, Size: 1819 bytes --]

From: Po Lu <luangruo@yahoo.com>
To: "Mattias Engdegård" <mattiase@acm.org>
Cc: Robert Pluim <rpluim@gmail.com>,  emacs-devel@gnu.org
Subject: Re: HAVE_FAST_UNALIGNED_ACCESS
Date: Thu, 30 Mar 2023 19:12:48 +0800
Message-ID: <87fs9mv6fj.fsf@yahoo.com>

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?


[-- Attachment #3: Type: text/plain, Size: 12 bytes --]


Robert
--