Dear sbcl developers,
here is a fix for bug 245 "bugs in disassembler", part a,
"On X86 an immediate operand for IMUL is printed incorrectly."
The bug description doesn't say what exactly is wrong. I found two
different incorrectnesses and believe that's all what is meant.
First, if the immediate value is less than -128 it is printed as a
large positive number:
(defun f (x)
(declare (optimize (speed 3) (safety 0))
(type fixnum x))
(the fixnum (* x -1000)))
; 095DD486: IMUL EDX, EDX, 4294966296 ; no-arg-parsing entry point
I suggest to fix that in src/compiler/x86/insts.lisp by defining a new
arg-type "signed-imm-word" and using that in the third :printer clause
in the definition of the "imul" instruction instead of the "imm-word"
used so far. A patch to that effect against sbcl-0.8.9 is attached.
Second, if the immediate value is between -128 and 127, it is printed as 0.
In the defun above, replace the -1000 by, say, 17 and disassemble again:
; 096001DE: IMUL EDX, EDX, 0 ; no-arg-parsing entry point
This happens because the caching mechanism in src/compiler/disassem.lisp
selects a wrong prefilter function for this flavor of the imul instruction.
More detailed: the chosen prefilter function is the same as the one for
the reg/mem-imm flavor (with a signed-imm-byte) of the "random arithmetic
inst" instructions ("add" etc.). This prefilter function puts the immediate
value into the third element of dstate-filtered-values whereas the printer
function from imul expects it in the fourth element.
To verify that this is an issue with the function cache simply move the
define-instruction of imul before the define-instruction of the random
arithmetic insts, rebuild sbcl and watch the disassembly of imul start
to work and the one of add etc. cease to work (on signed-imm-bytes).
A possible fix is to let "funstate-compatible-p" check the argument
positions for equality (in addition to the tests it does currently)
before declaring compatibility. Then a prefilter function is generated
specially for this flavor of imul which stores the immediate value in the
correct element. I have attached a patch to this effect, too.
I hope my explanation suffices for you to have faith in the fix. If not
please don't hesitate to ask for more info. I had to apropos, macroexpand,
insert format statements, rebuild sbcl and inspect a lot before I found
this and did not want to write that all down in this mail which is already
What I could not test is whether this breaks anything on non-x86 platforms.
With kind regards
lutz.euler@... (Lutz Euler) writes:
> here is a fix for bug 245 "bugs in disassembler", part a,
> "On X86 an immediate operand for IMUL is printed incorrectly."
Merged into 0.8.9.47. Thank you!
"Alas, the spheres of truth are less transparent than those of
illusion." -- L.E.J. Brouwer