fixed ebpf

xdp/Makefile

@@ -2,19 +2,42 @@ LLC ?= llc
 CLANG ?= clang
 CC ?= gcc
 
-all: bridge_xdp.o loader
+# 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
 
-bridge_xdp.o: bridge_xdp.c
+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__ \
-	    -I/usr/include/x86_64-linux-gnu \
+	    -D__TARGET_ARCH_$(ARCH) \
+	    -I/usr/include/$(MULTIARCH) \
 	    -Wall \
-	    -O2 -emit-llvm -c -o bridge_xdp.ll bridge_xdp.c
+	    -O2 -emit-llvm -c -o $*.ll $<
-	$(LLC) -march=bpf -filetype=obj -o bridge_xdp.o bridge_xdp.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 bridge_xdp.o bridge_xdp.ll loader
+	rm -f $(BPF_OBJS) *.ll loader af_xdp_user