[racket-dev] Another JIT question

I did:

@@ -1555,9 +1570,9 @@ typedef void (*Scheme_Invoke_Proc)(Scheme_Env
*env, intptr_t phase_shift,

 /* Exploit the fact that these should never be dereferenced: */
 #ifndef FIRST_TWO_BYTES_ARE_LEGAL_ADDRESSES
-# define MZ_EVAL_WAITING_CONSTANT ((Scheme_Object *)0x2)
-# define MZ_APPLY_WAITING_CONSTANT ((Scheme_Object *)0x4)
-# define MZ_MULTIPLE_VALUES_CONSTANT ((Scheme_Object *)0x6)
+# define MZ_EVAL_WAITING_CONSTANT ((Scheme_Object *)0x4)
+# define MZ_APPLY_WAITING_CONSTANT ((Scheme_Object *)0x8)
+# define MZ_MULTIPLE_VALUES_CONSTANT ((Scheme_Object *)0xc)
 #endif



On Sat, May 11, 2013 at 1:16 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> Wild guess: Did you change the pseudo-values MZ_EVAL_WAITING_CONSTANT
> and MZ_MULTIPLE_VALUES_CONSTANT to make sure they're not mistreated as
> immediates --- or that a character is not mistreated as a pseduo-value?
>
> At Sat, 11 May 2013 13:12:54 -0400, Jon Zeppieri wrote:
>> These all work:
>>
>> -> (write #\c)
>> #\c
>> -> (print #\c)
>> #\c
>> -> (display #\c)
>> c
>>
>> It really seems to be the case that only functions that return
>> characters have problems, and then, only those that return to the repo
>> loop. For instance:
>>
>> -> (write (values #\c))
>> #\c
>> -> (values #\c)
>> Segmentation fault: 11
>>
>>
>> On Sat, May 11, 2013 at 11:29 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
>> > The last example seems to be the only one that uses `write', while the
>> > others implicitly use `print'.
>> >
>> > Does
>> >
>> >  (write #\c)
>> >
>> > crash? How about
>> >
>> >  (print #\c)
>> >
>> > ?
>> >
>> > At Fri, 10 May 2013 21:19:25 -0400, Jon Zeppieri wrote:
>> >> My experiment with immediately represented characters has gotten to a
>> >> state where a non-JIT build passes all tests, but a JIT build fails
>> >> (as in, segfaults) on the following program:
>> >>
>> >> #\c
>> >>
>> >> It also fails on:
>> >>
>> >> (integer->char 99)
>> >>
>> >> and:
>> >>
>> >> (define (foo x) (integer->char x))
>> >> (foo 99)
>> >>
>> >> but not on:
>> >>
>> >> (define (foo x) (write (integer->char x)))
>> >> (foo 99)
>> >>
>> >> So there seems to be a problem returning a character from a jitted
>> >> function back to the repl. I haven't been able to figure out where
>> >> this occurs, though. gdb's stack traces don't seem very useful for
>> >> jitted code, and I can't use Sam's disassembler, because the process
>> >> dies.
>> >>
>> >> Any idea where to look or what debugging tools might be useful?
>> >>
>> >> -Jon
>> >> _________________________
>> >>   Racket Developers list:
>> >>   http://lists.racket-lang.org/dev