GNU bug report logs - #46111
Reverting fns.c hash function due to OpenBSD/SPARC64 compile breaking

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Ahmed Khanzada <me <at> enzu.ru>
Cc: eliz <at> gnu.org, 46111 <at> debbugs.gnu.org
Subject: bug#46111: Reverting fns.c hash function due to OpenBSD/SPARC64 compile breaking
Date: Thu, 28 Jan 2021 10:09:21 -0500

> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.