Steel Bank Common Lisp

On 2011-07-20, at 8:50 AM, Eric Marsden wrote:

> Hi,
> 
> On SBCL 1.0.50 on Linux/AMD64:
> 
> * (defun foo (x) (= #C(2.0 3.0) (the (complex single-float) x)))
> FOO
> *  (foo #C(1.0 2.0))
> CORRUPTION WARNING in SBCL pid 24208(tid 140737353934592):
> Memory fault at 0 (pc=0x100304f85f, sp=0x7ffff6d67520)
> The integrity of this image is possibly compromised.
> Continuing with fingers crossed.
> 0] backtrace
> 0: (SB-SYS:MEMORY-FAULT-ERROR)
> 1: ("foreign function: call_into_lisp")
> 2: ("foreign function: post_signal_tramp")
> 3: (FOO :INVALID-VALUE-FOR-UNESCAPED-REGISTER-STORAGE)
> 4: (SB-INT:SIMPLE-EVAL-IN-LEXENV (FOO #C(1.0 2.0)) #<NULL-LEXENV>)
> 5: (EVAL (FOO #C(1.0 2.0)))

This looks like an instruction encoding error.

DISASSEMBLE barfs on FOO, and gdb reveals:
0x1003077ee8:	popq   0x8(%rbp)
0x1003077eeb:	lea    -0x30(%rbp),%rsp
0x1003077eef:	cmp    $0x8,%rcx
0x1003077ef3:	jne    0x1003077f34
0x1003077ef5:	mov    %rdx,%rcx
0x1003077ef8:	mov    %ecx,%eax
0x1003077efa:	and    $0xf,%al
0x1003077efc:	cmp    $0xf,%al
0x1003077efe:	jne    0x1003077f3a
0x1003077f00:	mov    -0xf(%rcx),%al
0x1003077f03:	cmp    $0x26,%al
0x1003077f05:	jne    0x1003077f3a
0x1003077f07:	mov    %rcx,%rax
0x1003077f0a:	movq   -0x7(%rax),%xmm0
0x1003077f0f:	cmpeqps 0x3a(%rip),%xmm0        # 0x1003077f51 ***
0x1003077f17:	movmskps %xmm0,%rax
0x1003077f1b:	cmp    $0xf,%rax
0x1003077f1f:	mov    $0x20100017,%edx
0x1003077f24:	mov    $0x2010004f,%r11d
0x1003077f2a:	cmove  %r11,%rdx
0x1003077f2e:	mov    %rbp,%rsp
0x1003077f31:	clc    
0x1003077f32:	pop    %rbp
0x1003077f33:	retq   

That's right, 0x1003077f51. The values are actually at 0x1003077f50.

Paul Khuong

On 2011-07-20, at 8:50 AM, Eric Marsden wrote:

> Hi,
> 
> On SBCL 1.0.50 on Linux/AMD64:
> 
> * (defun foo (x) (= #C(2.0 3.0) (the (complex single-float) x)))
> FOO
> *  (foo #C(1.0 2.0))

It's indeed a bug in our encoding of RIP-relative EAs (a couple SSE instructions (shuffles and comparisons) have the interesting characteristic of not having the reg/mem operand as the last field). I can fix the assembler, but I have no clue how to get the disassembler right.

Paul Khuong

Hi,

Paul Khuong wrote:

> On 2011-07-20, at 8:50 AM, Eric Marsden wrote:
>
>> Hi,
>> 
>> On SBCL 1.0.50 on Linux/AMD64:
>> 
>> * (defun foo (x) (= #C(2.0 3.0) (the (complex single-float) x)))
>> FOO
>> *  (foo #C(1.0 2.0))
>
> It's indeed a bug in our encoding of RIP-relative EAs (a couple SSE
> instructions (shuffles and comparisons) have the interesting
> characteristic of not having the reg/mem operand as the last field).
> I can fix the assembler, but I have no clue how to get the
> disassembler right.

I volunteer to do the disassembler part. I'll wait for the assembler
part to be done and base a patch on that as some of the changes will
need to be textually very near to the assembler part.

Greetings,

Lutz

On 2011-07-20, at 8:50 AM, Eric Marsden wrote:

> Hi,
> 
> On SBCL 1.0.50 on Linux/AMD64:
> 
> * (defun foo (x) (= #C(2.0 3.0) (the (complex single-float) x)))
> FOO
> *  (foo #C(1.0 2.0))
> CORRUPTION WARNING in SBCL pid 24208(tid 140737353934592):
> Memory fault at 0 (pc=0x100304f85f, sp=0x7ffff6d67520)
> The integrity of this image is possibly compromised.
> Continuing with fingers crossed.
> 0] backtrace
> 0: (SB-SYS:MEMORY-FAULT-ERROR)
> 1: ("foreign function: call_into_lisp")
> 2: ("foreign function: post_signal_tramp")
> 3: (FOO :INVALID-VALUE-FOR-UNESCAPED-REGISTER-STORAGE)
> 4: (SB-INT:SIMPLE-EVAL-IN-LEXENV (FOO #C(1.0 2.0)) #<NULL-LEXENV>)
> 5: (EVAL (FOO #C(1.0 2.0)))

Fixed in 9d2548c Correct RIP-relative offset for strange x86-64 instructions.

Thanks for the nice report!

Paul Khuong

On 2011-07-22, at 9:01 AM, Lutz Euler wrote:
> 
> Paul Khuong wrote:
> 
>> On 2011-07-20, at 8:50 AM, Eric Marsden wrote:
>> 
>>> Hi,
>>> 
>>> On SBCL 1.0.50 on Linux/AMD64:
>>> 
>>> * (defun foo (x) (= #C(2.0 3.0) (the (complex single-float) x)))
>>> FOO
>>> *  (foo #C(1.0 2.0))
>> 
>> It's indeed a bug in our encoding of RIP-relative EAs (a couple SSE
>> instructions (shuffles and comparisons) have the interesting
>> characteristic of not having the reg/mem operand as the last field).
>> I can fix the assembler, but I have no clue how to get the
>> disassembler right.
> 
> I volunteer to do the disassembler part. I'll wait for the assembler
> part to be done and base a patch on that as some of the changes will
> need to be textually very near to the assembler part.

The assembler fix has just been committed (9d2548c Correct RIP-relative offset for strange x86-64 instructions).  The disassembler bug has been around for almost two years, and no one's complained yet, so we must be lucky (:

Paul Khuong

Hi,

The fix for this bug seems to have been incomplete. 

,----
| * (lisp-implementation-version)
| "1.0.51.6-d648683"
| * (funcall (lambda (x)
|              (declare (type (complex single-float) x))
|              (+ #C(0.0 1.0) x)) #C(1.0 2.0))
| CORRUPTION WARNING in SBCL pid 11171(tid 140737353930496):
| Memory fault at 0 (pc=0x100473a8ec, sp=0x7ffff6d67520)
| The integrity of this image is possibly compromised.
| Continuing with fingers crossed.
| debugger invoked on a SB-SYS:MEMORY-FAULT-ERROR:
|   Unhandled memory fault at #x0.
| 0] backtrace
| 0: (SB-SYS:MEMORY-FAULT-ERROR)
| 1: ("foreign function: call_into_lisp")
| 2: ("foreign function: post_signal_tramp")
| 3: ((LAMBDA (X)) :INVALID-VALUE-FOR-UNESCAPED-REGISTER-STORAGE)
`----

(Still on Linux/AMD64).

-- 
Eric Marsden

On 2011-08-23, at 7:39 AM, Eric Marsden wrote:

> Hi,
> 
> The fix for this bug seems to have been incomplete. 
> 
> ,----
> | * (lisp-implementation-version)
> | "1.0.51.6-d648683"
> | * (funcall (lambda (x)
> |              (declare (type (complex single-float) x))
> |              (+ #C(0.0 1.0) x)) #C(1.0 2.0))
> | CORRUPTION WARNING in SBCL pid 11171(tid 140737353930496):
> | Memory fault at 0 (pc=0x100473a8ec, sp=0x7ffff6d67520)
> | The integrity of this image is possibly compromised.
> | Continuing with fingers crossed.
> | debugger invoked on a SB-SYS:MEMORY-FAULT-ERROR:
> |   Unhandled memory fault at #x0.
> | 0] backtrace
> | 0: (SB-SYS:MEMORY-FAULT-ERROR)
> | 1: ("foreign function: call_into_lisp")
> | 2: ("foreign function: post_signal_tramp")
> | 3: ((LAMBDA (X)) :INVALID-VALUE-FOR-UNESCAPED-REGISTER-STORAGE)
> `----

That was actually an unrelated code generation bug.  Should be fixed in HEAD.

Thanks for the report again,

Paul Khuong