[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#46111: Reverting fns.c hash function due to OpenBSD/SPARC64 compile
From: |
Stefan Monnier |
Subject: |
bug#46111: Reverting fns.c hash function due to OpenBSD/SPARC64 compile breaking |
Date: |
Thu, 28 Jan 2021 10:09:21 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
> Starting program: /home/enzuru/src/emacs/src/bootstrap-emacs
>
> Breakpoint 1, hash_string (ptr=0x47fa34d596 "DndProtocol", len=11) at
> fns.c:4602
> 4602 EMACS_UINT const *p = (EMACS_UINT const *) ptr;
> (gdb) info args
> ptr = 0x47fa34d596 "DndProtocol"
> len = 11
> (gdb) next
> 4603 EMACS_UINT const *end = (EMACS_UINT const *) (ptr + len);
> (gdb) next
> 4604 EMACS_UINT hash = len;
> (gdb) next
> 4607 ptrdiff_t step = 1 + ((end - p) >> 3);
> (gdb) next
> 4611 while (p <= end - 1)
> (gdb) next
> 4613 EMACS_UINT c = *p;
> (gdb) next
>
> Program received signal SIGBUS, Bus error.
Hmm... so it's doing a dereference at address 0x47fa34d596 and getting
a bus error?
I have two questions here:
- I'd guess that the bus error is due to alignment restrictions.
What hardware is this running on? Last I checked, the computer
architecture community had agreed (many years ago already) that
(except for very small CPUs maybe, those not able to run Emacs) it's
better to have the hardware support unaligned memory accesses (it took
more time to get there than the consensus on branch delay slots,
admittedly), so I'd be curious if there is still moderately recent
hardware that insists on signaling an error.
- AFAICT from the backtrace, `ptr` points to a plain normal ELisp
string's content, yet these are supposed to be aligned, so what's
going on here (this question is not directed at you ;-)
Stefan
- bug#46111: Reverting fns.c hash function due to OpenBSD/SPARC64 compile breaking, Ahmed Khanzada, 2021/01/26
- bug#46111: Reverting fns.c hash function due to OpenBSD/SPARC64 compile breaking, Ahmed Khanzada, 2021/01/26
- bug#46111: Reverting fns.c hash function due to OpenBSD/SPARC64 compile breaking, Eli Zaretskii, 2021/01/26
- bug#46111: Reverting fns.c hash function due to OpenBSD/SPARC64 compile breaking, Ahmed Khanzada, 2021/01/27
- bug#46111: Reverting fns.c hash function due to OpenBSD/SPARC64 compile breaking, Eli Zaretskii, 2021/01/28
- bug#46111: Reverting fns.c hash function due to OpenBSD/SPARC64 compile breaking,
Stefan Monnier <=
- bug#46111: Reverting fns.c hash function due to OpenBSD/SPARC64 compile breaking, Eli Zaretskii, 2021/01/28
- bug#46111: Reverting fns.c hash function due to OpenBSD/SPARC64 compile breaking, Stefan Monnier, 2021/01/28
- bug#46111: Reverting fns.c hash function due to OpenBSD/SPARC64 compile breaking, Stefan Monnier, 2021/01/28
- bug#46111: Reverting fns.c hash function due to OpenBSD/SPARC64 compile breaking, Stefan Monnier, 2021/01/28
- bug#46111: Reverting fns.c hash function due to OpenBSD/SPARC64 compile breaking, Andreas Schwab, 2021/01/28
- bug#46111: Reverting fns.c hash function due to OpenBSD/SPARC64 compile breaking, Eli Zaretskii, 2021/01/28
- bug#46111: Reverting fns.c hash function due to OpenBSD/SPARC64 compile breaking, Stefan Monnier, 2021/01/28
- bug#46111: Reverting fns.c hash function due to OpenBSD/SPARC64 compile breaking, Andreas Schwab, 2021/01/28
- bug#46111: Reverting fns.c hash function due to OpenBSD/SPARC64 compile breaking, Stefan Monnier, 2021/01/28
bug#46111: Reverting fns.c hash function due to OpenBSD/SPARC64 compile breaking, Philipp Stephani, 2021/01/26