mirror of
https://github.com/tinygo-org/tinygo.git
synced 2026-07-26 06:38:42 +00:00
iamrajiv
f16697624d
When the interpreter encountered a load that was out of bounds of the
object, it panicked with "interp: load out of bounds", crashing the
compiler. This can happen for valid Go programs, for example when
dereferencing the pointer returned by unsafe.SliceData on a
zero-capacity slice, which points to a zero-sized object:
package main
import "unsafe"
var p = unsafe.SliceData([]int{})
var v = *p
func main() {}
Return nil for an out-of-bounds load, the same as for an external
global, so the caller defers the load to runtime instead of crashing.
This matches what regular Go does, where the load reads from the
runtime zero-base at runtime.
Fixes #4214
24 lines
706 B
LLVM
24 lines
706 B
LLVM
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
|
|
target triple = "x86_64--linux"
|
|
|
|
; Reproduction of https://github.com/tinygo-org/tinygo/issues/4214.
|
|
; Dereferencing the pointer returned by unsafe.SliceData on a zero-capacity
|
|
; slice produces a load that is out of bounds of a zero-sized object. The
|
|
; interp must defer this load to runtime instead of crashing the compiler.
|
|
|
|
@main.zeroSized = global {} zeroinitializer
|
|
@main.v = global i64 0
|
|
|
|
define void @runtime.initAll() unnamed_addr {
|
|
entry:
|
|
call void @main.init(ptr undef)
|
|
ret void
|
|
}
|
|
|
|
define internal void @main.init(ptr %context) unnamed_addr {
|
|
entry:
|
|
%val = load i64, ptr @main.zeroSized
|
|
store i64 %val, ptr @main.v
|
|
ret void
|
|
}
|