[racket-dev] Another JIT question

Relatedly, does this crash?

(parameterize ([current-input-port (open-input-string "#\\c")])
(read-eval-print-loop))

Robby


On Sat, May 11, 2013 at 12:28 PM, Robby Findler <robby at eecs.northwestern.edu
> wrote:

> Did you try to pull out and simplify read-eval-print-loop until you can
> get a stand-alone program that crashes? (The impl is in
> racket/private/misc.rkt.)
>
> Robby
>
>
> On Sat, May 11, 2013 at 12:19 PM, Jon Zeppieri <zeppieri at gmail.com> wrote:
>
>> 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
>> _________________________
>>   Racket Developers list:
>>   http://lists.racket-lang.org/dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20130511/675f5aec/attachment.html>