On Sun, 2024-04-07 01:42:49 +0900, Rin Okuyama <rokuyama.rk%gmail.com@localhost> wrote:
> On 2024/04/07 1:16, Jan-Benedict Glaw wrote:
> > What the heck?! The original output (full unimpl_emul.S) was
> > different, but the critical excerpt is no longer? That'll be "fun" to
> > debug. Unfortunately, paid work is demanding right now, that might
> > take a while for me to really work on...
>
> Yeah, I assembled unimpl_emul.S on NetBSD/amd64 and aarch64{,eb}
> hosts, and obtained different values in immediate fields of the
> instructions.
>
> There should be bugs in gas logic handling floating-point immediates.
>
> Note also:
>
> - MALLOC_CONF="junk:true" (for NetBSD jemalloc) does not affect
> the results.
>
> - This is not a recent regression; objdump for GENERIC kernel of
> NetBSD/vax 5.0 has the same bit pattern as NetBSD 10.0 in the insns.
>
> It would be nice if we can fix gas, but cannot we replace $0f0.0 with
> $0x0 for now? According to "Vax Architecture Handbook", a floating-
> point number is recognized as 0.0 if sign and exponent fields are zero,
> and CPU always generates 0x0 for 0.0.
I haven't even _looked_ at the code, so I don't know what it's
actually doing. I don't know the FP representation out of my head, but
if an all-zero value is interpreted as 0.0, a CLRx would probably be
enough? Still, I'd like to see that bug fixed (and maybe add a
testcase for it to upstream Binutils.)
Unfortunately, I guess I'll only have time for this in a month or
the like, maybe you, or Kalvin, or Anders, or Martin, or Maciej, or
Mouse, or ... may want to have a look? Esp, since it happened in a
regular CI build, but I was unable (in a few-minutes attempt) to
reproduce it. :-/ I'd like to make sure there isn't much more hidden
behind this issue.
MfG, JBG
--
Attachment:
signature.asc
Description: PGP signature