#!/usr/bin/env bash # Does a --x86 --dev build actually call through the indirection cell? # # survey.sh cannot answer this and no program can. A dev build begins with # every cell pointing at the body this build compiled, so it prints exactly # what a release build prints whether the call reads the cell or ignores it. # The only way to tell is to change what a cell holds and see whether anything # notices. # # So: cell-override.c is preloaded, and its constructor looks up # flan.cell.twice with dlsym and stores a different body there. No compiler is # involved and nothing is redefined in the language's sense -- this is just the # one store a redefinition ends in, done from outside. # # Four builds, and the two controls are half the test: # # llvm --dev cell is read -> 22 22 # x86 --dev cell is read -> 22 22 (this lane's claim) # llvm no cell -> 42 42 (dlsym answers NULL) # x86 no cell -> 42 42 # # The release rows are what say the change came from the indirection and not # from ordinary symbol interposition. set -u here=$(cd "$(dirname "$0")" && pwd) root=$(cd "$here/../.." && pwd) cd "$root" || exit 1 dune build --root . bin/main.exe 2>&1 | head -30 flan=$root/_build/default/bin/main.exe test -x "$flan" || { echo "build failed"; exit 1; } out=$(mktemp -d); trap 'rm -rf "$out"' EXIT cc -shared -fPIC -o "$out/override.so" "$here/cell-override.c" || exit 1 src=$here/p8-cell.flan fail=0 run() { # run