Disassembly lines broken by comments in 1.1.12

Bug #1249205 reported by Ph. Marek
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
Fix Released
Medium
Unassigned

Bug Description

Given this function:

(defun XXX (inp)
  (format t "~(~a~^~)~%" inp))

Clling disassemble on debian sbcl=2:1.1.12-1 gives this in the TCP connection from swank:

; DAC: FF5009 CALL QWORD PTR [RAX+9]
; DAF: 480F42E3 CMOVB RSP, RBX
; DB3: 48
;;; [2] (BLOCK XXX (FORMAT T "~(~a~^~)~%" INP))

8BFA MOV RDI, RDX
; DB6: 48897DF0 MOV [RBP-16], RDI
; DBA: 488D5C24F0 LEA RBX, [RSP-16]
; DBF: 4883EC18 SUB RSP, 24

Ie. the comment line disrupts an assembly line.

My .sbclrc includes

(declaim (optimize (debug 3) (safety 3)))

Revision history for this message
Stas Boukarev (stassats) wrote :

You're better off disabling source annottations, it's patently useless.
(setf sb-ext:*disassemble-annotate* nil)

Revision history for this message
Paul Khuong (pvk) wrote :

That's intended. Notice the triple colons.

Changed in sbcl:
status: New → Invalid
Revision history for this message
Stas Boukarev (stassats) wrote :

I think the issues is that an instruction is split by the annotation, spciefically, the REX prefix seems to be not counted when annotating.

Changed in sbcl:
status: Invalid → Confirmed
Revision history for this message
Lutz Euler (lutz-euler) wrote :

This behaviour was introduced with my commit 65bdee4ba534e82c352cff3eec16473daaf285dd "Improve handling of x86[-64] prefix instructions in the disassembler.". I'll see what I can do about it.

tags: added: disassembler x86-64
Changed in sbcl:
status: Confirmed → In Progress
assignee: nobody → Lutz Euler (lutz-euler)
importance: Undecided → Medium
Revision history for this message
Lutz Euler (lutz-euler) wrote :

Investigation shows that actually commit 65bdee4ba534e82c352cff3eec16473daaf285dd only uncovered a quirk that already existed when SBCL was forked from CMUCL, namely that the offsets of source tracking hooks are (at least in this function) wrong by a constant offset. There is even a „FIX“ note in ADD-SOURCE-TRACKING-HOOKS (in src/compiler/target-disassem.lisp):

(flet ((add-hook (pc fun &optional before-address)
           (push (make-offs-hook
                  :offset pc ;; ### FIX to account for non-zero offs in code
                  :fun fun
                  :before-address before-address)
                 (seg-hooks segment))))
  …)

Due to this offset the annotations firstly are printed at completely wrong places, secondly are only printed at all if this wrong place happens to coincide with the start of an instruction, thirdly, since the mentioned commit, are more often printed as now in instructions with prefixes multiple positions qualify as the start of the instruction; and, if a position after the first prefix is hit, the reported broken lines ensue.

I intend to look into fixing this next.

Revision history for this message
Lutz Euler (lutz-euler) wrote :
Download full text (3.2 KiB)

As a hint towards what could be expected from a fix, with a hack that just corrects the offset for this specific function its dissassembly looks like this:

; disassembly for XXX
; Size: 204 bytes
; 0439922D: 498B442450 MOV RAX, [R12+80] ; no-arg-parsing entry point
; 32: 4883C010 ADD RAX, 16
; 36: 48C740F851000000 MOV QWORD PTR [RAX-8], 81
; 3E: 488968F0 MOV [RAX-16], RBP
; 42: 4989442450 MOV [R12+80], RAX

;;; [2] (BLOCK XXX (FORMAT T "~(~a~^~)~%" INP))

; 47: 488B056AFFFFFF MOV RAX, [RIP-150] ; '*STANDARD-OUTPUT*
; 4E: 488B5021 MOV RDX, [RAX+33]
; 52: 498B1414 MOV RDX, [R12+RDX]
; 56: 4883FA61 CMP RDX, 97
; 5A: 7504 JNE L0
; 5C: 488B50F9 MOV RDX, [RAX-7]
; 60: L0: 4883FA51 CMP RDX, 81
; 64: 0F848A000000 JEQ L1

;;; [3] (FORMAT T "~(~a~^~)~%" INP)

; 6A: 488D5C24F0 LEA RBX, [RSP-16]
; 6F: 4883EC18 SUB RSP, 24
; 73: 488B3D46FFFFFF MOV RDI, [RIP-186] ; :DOWNCASE
; 7A: 488B0547FFFFFF MOV RAX, [RIP-185] ; #<FDEFINITION object for SB-INT:MAKE-CASE-FROB-STREAM>
; 81: B904000000 MOV ECX, 4
; 86: 48892B MOV [RBX], RBP
; 89: 488BEB MOV RBP, RBX
; 8C: FF5009 CALL QWORD PTR [RAX+9]
; 8F: 480F42E3 CMOVB RSP, RBX
; 93: 488BFA MOV RDI, RDX
; 96: 488BF7 MOV RSI, RDI
; 99: 488975F0 MOV [RBP-16], RSI
; 9D: 488D5C24F0 LEA RBX, [RSP-16]
; A2: 4883EC18 SUB RSP, 24
; A6: 488B55F8 MOV RDX, [RBP-8]
; AA: 488BFE MOV RDI, RSI
; AD: 488B051CFFFFFF MOV RAX, [RIP-228] ; #<FDEFINITION object for PRINC>
; B4: B904000000 MOV ECX, 4
; B9: 48892B MOV [RBX], RBP
; BC: 488BEB MOV RBP, RBX
; BF: FF5009 CALL QWORD PTR [RAX+9]
; C2: 488B75F0 MOV RSI, [RBP-16]

; C6: 498B442450 MOV RAX, [R12+80]
; CB: 48C740F000000000 MOV QWORD PTR [RAX-16], 0
; D3: 48C740F800000000 MOV QWORD PTR [RAX-8], 0
; DB: 4883E810 SUB RAX, 16
; DF: 4989442450 MOV [R12+80], RAX
; E4: BA17001020 MOV EDX, 537919511
; E9: 488BE5 MOV RSP, RBP
; EC: F8 CLC
; ED: 5D POP RBP
; EE: C3 RET
; EF: CC0A BREAK 10 ; error trap
; F1: 02 BYTE #X02
; F2: 19 BYTE #X19 ; INVALID-ARG-COUNT-ERROR
; F3: 9A BYTE #X9A ; RCX
; F4: L1: CC0A BREAK 10 ; error trap
; F6: 02 BYTE #X02
; F7: 1B BYTE #X1B ...

Read more...

Revision history for this message
Lutz Euler (lutz-euler) wrote :

I have just committed a fix as ca5da65d5835b3bf67389c70eeb7503d27e1eedd.

Changed in sbcl:
status: In Progress → Fix Committed
assignee: Lutz Euler (lutz-euler) → nobody
Changed in sbcl:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.