[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects
From: |
Eli Zaretskii |
Subject: |
bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects |
Date: |
Sat, 30 May 2020 19:32:46 +0300 |
> From: Pip Cet <pipcet@gmail.com>
> Date: Sat, 30 May 2020 13:29:33 +0000
> Cc: eggert@cs.ucla.edu, 41321@debbugs.gnu.org,
> Stefan Monnier <monnier@iro.umontreal.ca>
>
> > > > So this alignment requirement is only due to pthreads being used?
> > >
> > > I'm not sure what you're asking. Obviously there are systems on which
> > > unaligned accesses will fault or be very slow indeed, so we need to
> > > make sure, say, pure space allocations are aligned somehow. That
> > > requires a LISP_ALIGNMENT of 8. Everything beyond that is only for
> > > performance, pthreads, and SIMD types.
> >
> > If the system guarantees 4-byte alignment from malloc (and/or a
> > similar alignment of the runtime C stack), then using that doesn't
> > trigger problems related to unaligned accesses, right? So let me
> > rephrase: why isn't 4-byte alignment "good enough" for us on systems
> > where malloc and the runtime stack are guaranteed to be thus aligned?
>
> (The runtime stack isn't relevant, as far as I can tell, since we walk
> that in 4-byte steps on such systems anyway.)
I think it might be relevant for stack-based Lisp objects (if we keep
requiring that Lisp objects are 8-byte aligned on 32-bit platforms).
> You're correct that on such a system, we could get away with a
> LISP_ALIGNMENT of 4, but a LISP_ALIGNMENT of 8 wouldn't hurt either.
That's for sure. I just wondered why did we start requiring 8-byte
alignment back when we did. Perhaps someone still remembers the
reason.
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, (continued)
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Paul Eggert, 2020/05/28
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Eli Zaretskii, 2020/05/29
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Paul Eggert, 2020/05/29
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Pip Cet, 2020/05/29
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Eli Zaretskii, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Pip Cet, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Eli Zaretskii, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Pip Cet, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Eli Zaretskii, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Pip Cet, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects,
Eli Zaretskii <=
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Pip Cet, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Eli Zaretskii, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Paul Eggert, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Pip Cet, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Eli Zaretskii, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Paul Eggert, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Pip Cet, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Paul Eggert, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Pip Cet, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Paul Eggert, 2020/05/30