Currently, failed dereferences in bits->values result in an invalid memory reference error:
hoax/ $ racket
Welcome to Racket v9.0 [cs].
> (require "types.rkt")
> (bits->value 1)
invalid memory reference. Some debugging context lost [,bt for context]
>
This happens when the call to ptr-ref fails due to an invalid or out-of-bounds pointer, resulting in a segfault. These issues can be tricky for students to diagnose because they cannot be distinguished from invalid memory references during student code execution.
One step we can take is to track the heap pointer allocated by the call to malloc in a86/interp.rkt:
|
;; WARNING: The heap is re-used, so make sure you're done with it |
|
;; before calling asm-interp again |
|
(define *heap* |
|
; IMPROVE ME: hard-coded heap size |
|
(malloc _int64 20000 'raw)) |
Then, in the types.rkt code of a compiler implementation, we could compare the value passed to bits->value to ensure it falls within the range between the heap pointer and its upper limit (deduced from its size).
Currently, failed dereferences in
bits->valuesresult in aninvalid memory referenceerror:This happens when the call to ptr-ref fails due to an invalid or out-of-bounds pointer, resulting in a segfault. These issues can be tricky for students to diagnose because they cannot be distinguished from invalid memory references during student code execution.
One step we can take is to track the heap pointer allocated by the call to
mallocina86/interp.rkt:a86/a86/interp.rkt
Lines 50 to 54 in 3874964
Then, in the
types.rktcode of a compiler implementation, we could compare the value passed tobits->valueto ensure it falls within the range between the heap pointer and its upper limit (deduced from its size).