Custom Query (1030 matches)

This function is derived from cmucl-type-prop.13 from the test suite. The ARM compiler appears to mis-compile it.

Welcome to Clozure Common Lisp Version 1.7-dev-r14779  (LinuxARM32)!
? (defun junk (p1)
  (declare (optimize (speed 2) (safety 2) (debug 1) (space 3))
	   (type (eql 64848.973) p1))
  (- (the (eql 64848.973f0) p1) -2808/1031))
JUNK
? (junk 64848.973)
> Error: value 353705262 is not of the expected type MACPTR.
> While executing: FUNCALL-WITH-XP-STACK-FRAMES, in process listener(1).
> Type :POP to abort, :R for a list of available restarts.
> Type :? for other options.
1 > (disassemble 'junk)
;;; (defun junk (p1) (declare (optimize (speed 2) (safety 2) (debug 1) (space 3)) (type (eql 64848.973) 
  (cmp nargs (:$ 4))
  (beq L12)
  (uuo-error-wrong-nargs (:? ne))
L12
  (mov imm0 (:$ 19))
  (stmdb (:! sp) (imm0 vsp fn lr))
  (mov fn temp2)
  (str arg_z (:@! vsp (:$ -4)))         ;[24]
NIL
1 > 

gdb shows the following disassembly:

   0x54549594:	cmp	r2, #4
   0x54549598:	beq	0x545495a0
   0x5454959c:			; <UNDEFINED> instruction: 0x17f001f8
   0x545495a0:	mov	r0, #19
   0x545495a4:	push	{r0, r10, r11, lr}
   0x545495a8:	mov	r11, r9
   0x545495ac:	str	r4, [r10, #-4]!
   0x545495b0:	andeq	r0, r0, r0
   0x545495b4:	andeq	r0, r0, r9
   0x545495b8:	andeq	r0, r0, r10, lsr #10
   0x545495bc:	ldrbpl	r9, [r4], #-1428	; 0x594
   0x545495c0:	ldrbpl	r9, [r4], #-1430	; 0x596
   0x545495c4:	ldrbpl	r9, [r4], #-1613	; 0x64d
   0x545495c8:	strtpl	r12, [r12], #-1686	; 0x696
   0x545495cc:	andeq	r0, r0, #0
   0x545495d0:	andeq	r0, r0, r10, ror r8
   0x545495d4:	strtpl	sp, [r0], #-1829	; 0x725
   0x545495d8:	ldrbpl	r9, [r4], #-1534	; 0x5fe
   0x545495dc:	ldrbpl	r9, [r4], #-2198	; 0x896
   0x545495e0:	andeq	r0, r0, r0, lsl #1

On Windows, one creates a new process with ​CreateProcess, which accepts a string parameter that contains the command line for the newly created process.

In the newly created process, C runtime code then parses this string and constructs argc and argv[]. The rules used to do this are described by ​http://msdn.microsoft.com/en-us/library/a1y7w461.aspx.

We need to apply the inverse of those rules to the command and arguments given to run-program so that the the newly created process sees the same argv[] that the user provided to run-program.

Currently, we just join the all the argument strings together with #\space and call it a day.

r11754 is workaround for a bug in how the lisp assembler encodes memory operands that are just a displacement.

To elaborate on that commit message, there are two ways on 32-bit x86 to encode a memory operand that's just a displacement.

For example, take the instruction:

0x806e6db:	mov    %fs:0x84,%ecx

The lisp assembler encodes this as:

0x806e6db:	0x64	0x8b	0x0c	0x25	0x84	0x00	0x00	0x00

Note that the modrm byte of 0x0c (00 001 100) means that a sib byte follows.

This could also be encoded as this shorter sequence (and the Unix assembler does so):

0x806e6db:	0x64	0x8b	0x0d	0x84	0x00	0x00	0x00

The modrm byte of 0x0d (00 001 101) here means that the displacement follows.

The reason that the lisp assembler selects the longer encoding is because it targeted x86-64 first. On x86-64, the modrm byte in the shorter sequence is redefined to mean that the displacement is RIP-relative. Therefore, the longer sib byte encoding is used to specify just a displacement.

The lisp assembler needs to be persuaded to emit the shorter encoding for 32-bit x86. When it does, we can recompile and bump fasl versions, etc., and remove the workaround in pc_luser_xp().