[racket-dev] Another JIT question

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