New Zealand
Comment by ~ach on ~sircmpwn/hare
I noticed that _start is provided by libc, so I wonder how libc knows to invoke the hare initialization? I think it might be just jumping straight to main and skipping your initialization (and exit) code.
Comment by ~ach on ~sircmpwn/hare
I have resolved this issue - the problem was nixos setting LD to 'ld' which meant hare was using ld even when -lc was passed. The symptom of this is a successful link, but the _start symbol is missing. This manifests as a segfault.
Comment by ~ach on ~sircmpwn/hare
Another reproduction of the issue with -v:
https://builds.sr.ht/~ach/job/757977
hare is clearly using the wrong linker despite the fact -lc is being passed. No crt.o files are being linked, hence the missing _start.
edit: sorry this build doesn't show the issue, my mistake, will post another.
Comment by ~ach on ~sircmpwn/hare
Ok after more digging, the program is being linked with ld, when it should be using $CC.
Comment by ~ach on ~sircmpwn/hare
harec -o /run/user/1000/18e935ef9b76661c/temp.rt.0.ssa -N rt -t /home/ac/.cache/hare/rt/d9cd48a95d3312fe4cc7e40948de7e3b22a44e77f1f25a8e2e55649236dd72d7.td /home/ac/local/src/hare/stdlib/rt/+linux/+x86_64.ha /home/ac/local/src/hare/stdlib/rt/+linux/abort.ha /home/ac/local/src/hare/stdlib/rt/+linux/env.ha /home/ac/local/src/hare/stdlib/rt/+linux/errno.ha /home/ac/local/src/hare/stdlib/rt/+linux/platformstart+libc.ha /home/ac/local/src/hare/stdlib/rt/+linux/prctl.ha /home/ac/local/src/hare/stdlib/rt/+linux/segmalloc.ha /home/ac/local/src/hare/stdlib/rt/+linux/signal.ha /home/ac/local/src/hare/stdlib/rt/+linux/socket.ha /home/ac/local/src/hare/stdlib/rt/+linux/stat.ha /home/ac/local/src/hare/stdlib/rt/+linux/syscallno+x86_64.ha /home/ac/local/src/hare/stdlib/rt/+linux/syscalls.ha /home/ac/local/src/hare/stdlib/rt/+linux/types.ha /home/ac/local/src/hare/stdlib/rt/+x86_64/backtrace.ha /home/ac/local/src/hare/stdlib/rt/+x86_64/cpuid.ha /home/ac/local/src/hare/stdlib/rt/+x86_64/jmp.ha /home/ac/local/src/hare/stdlib/rt/abort.ha /home/ac/local/src/hare/stdlib/rt/ensure.ha /home/ac/local/src/hare/stdlib/rt/fenv_defs.ha /home/ac/local/src/hare/stdlib/rt/jmp.ha /home/ac/local/src/hare/stdlib/rt/malloc+libc.ha /home/ac/local/src/hare/stdlib/rt/memcpy.ha /home/ac/local/src/hare/stdlib/rt/memmove.ha /home/ac/local/src/hare/stdlib/rt/memset.ha /home/ac/local/src/hare/stdlib/rt/start+libc.ha /home/ac/local/src/hare/stdlib/rt/strcmp.ha qbe -o /run/user/1000/18e935ef9b76661c/temp.rt.1.s /run/user/1000/18e935ef9b76661c/temp.rt.0.ssa x86_64-unknown-linux-musl-as -g -o /run/user/1000/18e935ef9b76661c/temp.rt.2.o /run/user/1000/18e935ef9b76661c/temp.rt.1.s x86_64-unknown-linux-musl-as -g -o /run/user/1000/18e935ef9b76661c/temp.rt.3.o /home/ac/local/src/hare/stdlib/rt/+linux/syscall+x86_64.s x86_64-unknown-linux-musl-as -g -o /run/user/1000/18e935ef9b76661c/temp.rt.4.o /home/ac/local/src/hare/stdlib/rt/+x86_64/cpuid_native.s x86_64-unknown-linux-musl-as -g -o /run/user/1000/18e935ef9b76661c/temp.rt.5.o /home/ac/local/src/hare/stdlib/rt/+x86_64/fenv.s x86_64-unknown-linux-musl-as -g -o /run/user/1000/18e935ef9b76661c/temp.rt.6.o /home/ac/local/src/hare/stdlib/rt/+x86_64/getfp.s x86_64-unknown-linux-musl-as -g -o /run/user/1000/18e935ef9b76661c/temp.rt.7.o /home/ac/local/src/hare/stdlib/rt/+x86_64/longjmp.s x86_64-unknown-linux-musl-as -g -o /run/user/1000/18e935ef9b76661c/temp.rt.8.o /home/ac/local/src/hare/stdlib/rt/+x86_64/restore.s x86_64-unknown-linux-musl-as -g -o /run/user/1000/18e935ef9b76661c/temp.rt.9.o /home/ac/local/src/hare/stdlib/rt/+x86_64/setjmp.s x86_64-unknown-linux-musl-ar -csr /home/ac/.cache/hare/rt/d9cd48a95d3312fe4cc7e40948de7e3b22a44e77f1f25a8e2e55649236dd72d7.a /run/user/1000/18e935ef9b76661c/temp.rt.2.o /run/user/1000/18e935ef9b76661c/temp.rt.3.o /run/user/1000/18e935ef9b76661c/temp.rt.4.o /run/user/1000/18e935ef9b76661c/temp.rt.5.o /run/user/1000/18e935ef9b76661c/temp.rt.6.o /run/user/1000/18e935ef9b76661c/temp.rt.7.o /run/user/1000/18e935ef9b76661c/temp.rt.8.o /run/user/1000/18e935ef9b76661c/temp.rt.9.o
The build driver is not picking up the assembly file containing the libc start symbol.
Comment by ~ach on ~sircmpwn/hare
So my binaries with -lc are missing the _start symbol so just pick a random address then crash.
Ticket created by ~ach on ~sircmpwn/hare
I was unable to get a working program using 'hare build -lc' or 'hare build -T +libc -lc' on nixos. I seem to have been able to reproduce the issue on alpine:
This is usually caused when the input program has a code path that uses a variable before it has been assigned in the C code. Unfortunately currently cproc cannot see this code path and qbe chokes on it which is why the error message is not so pleasant
Usually the fix is to work out which function in the input is using an undefined variable and fixing it upstream.
Just to prune, I think running real world programs (like gcc bootstrap) is a better test.
REPORTED
RESOLVED FIXEDI think the chibicc preprocessor is another good one: https://github.com/rui314/chibicc/blob/main/preprocess.c
It is very small and handles a lot of real programs.