LLC ?= llc
CLANG ?= clang
CC ?= gcc

# Detecta a arquitetura de verdade em vez de fixar x86_64 (o host de
# produção é ARM64/aarch64 — Oracle Ampere). O diretório de headers da
# libc varia por arquitetura (/usr/include/<triplet>/), então isso
# precisa ser dinâmico ou o -I aponta pra um caminho que nunca existiu
# nesta máquina.
# Mesmo mapeamento usado no Makefile do ebpf-sockmap (convenção libbpf/CO-RE:
# __TARGET_ARCH_arm64, não __TARGET_ARCH_aarch64).
ARCH        := $(shell uname -m | sed 's/x86_64/x86/' | sed 's/aarch64/arm64/')
MULTIARCH   := $(shell $(CC) -dumpmachine 2>/dev/null)
BPF_OBJS    := bridge_xdp.o xdp_ddos_filter.o xdp_wg_mtu_optimizer.o

all: $(BPF_OBJS) loader af_xdp_user

# Regra genérica: qualquer programa XDP (.c -> .ll -> .o) segue o mesmo
# caminho de compilação. Antes só existia a regra explícita pra
# bridge_xdp.o — xdp_ddos_filter.o e xdp_wg_mtu_optimizer.o que estavam
# na pasta foram gerados por fora do Makefile, então "make" nunca os
# reconstruía depois de editar o .c correspondente.
%.o: %.c
	$(CLANG) -S \
	    -target bpf \
	    -D __BPF_TRACING__ \
	    -D__TARGET_ARCH_$(ARCH) \
	    -I/usr/include/$(MULTIARCH) \
	    -Wall \
	    -O2 -emit-llvm -c -o $*.ll $<
	$(LLC) -march=bpf -filetype=obj -o $@ $*.ll

loader: loader.c
	$(CC) -Wall -o loader loader.c -l:libbpf.a -lelf -lz

# af_xdp_user.c é userspace puro (usa só headers de kernel/libc via
# syscalls diretos: socket(AF_XDP), setsockopt, mmap) — não precisa
# linkar libbpf.
af_xdp_user: af_xdp_user.c
	$(CC) -Wall -O2 -o af_xdp_user af_xdp_user.c

clean:
	rm -f $(BPF_OBJS) *.ll loader af_xdp_user