# Fil-C 사용에 대한 djb의 노트 > Clean Markdown view of GeekNews topic #24102. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24102](https://news.hada.io/topic?id=24102) - GeekNews Markdown: [https://news.hada.io/topic/24102.md](https://news.hada.io/topic/24102.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-11-03T09:47:10+09:00 - Updated: 2025-11-03T09:47:10+09:00 - Original source: [cr.yp.to](https://cr.yp.to/2025/fil-c.html) - Points: 2 - Comments: 1 ## Topic Body - **메모리 안전성**을 갖춘 새로운 C/C++ 컴파일러 **Fil-C**는 기존 코드와의 **높은 호환성**을 보이며, 대부분의 라이브러리와 애플리케이션이 수정 없이 작동 - Debian 13 환경에서 Fil-C를 **소스 빌드 및 설치**하는 절차와, glibc·binutils를 Fil-C로 재컴파일하는 **자동 설치 스크립트** 제공 - 약 **9000개 암호화 소프트웨어 마이크로벤치마크**에서 Fil-C는 clang 대비 **1~4배의 사이클 수**를 사용 - Fil-C로 **Debian 패키지 빌드 체계 통합**을 시도하며, 새로운 ABI(`amd64fil0`)를 추가해 **Fil-C 기반 패키지 병행 설치** 가능 구조 제시 - Fil-C는 **메모리 안전성과 기존 생태계 호환성**을 동시에 추구하며, Debian 기반 시스템으로의 확장 가능성을 보여줌 --- ### Fil-C 개요 및 초기 인상 - Fil-C는 **메모리 안전성을 보장하는 C/C++ 컴파일러**로, 기존 코드와의 **높은 호환성**을 보임 - 대부분의 라이브러리와 애플리케이션이 수정 없이 작동 - 예외적으로 수정이 필요한 경우도 해결이 어려운 수준은 아님 - 작성자는 관리 중인 여러 시스템을 **Fil-C로 컴파일된 코드로 전환**해 보호하는 것을 목표로 함 - 테스트 환경은 **Debian 13**, AMD Ryzen 5 7640HS(6코어 12스레드), 12GB RAM, 36GB 스왑 메모리 ### 관련 자료 및 스크립트 - Fil-C와 상위 소스(예: clang, glibc) 간의 차이를 비교하는 **감사용 diff 스크립트** 공개 - Debian 13에서 Fil-C, glibc, binutils를 다운로드·컴파일·설치하는 **filian-install-compiler** 스크립트 제공 - 전체 실행 시간: 실시간 86분, 사용자 시간 477분, 시스템 시간 52분 - Fil-C를 이용해 Debian 소스 패키지를 빌드하는 **filian-install-packages** 스크립트 제공 - 일부 패키지(bzip2 등)는 정상 빌드 확인 - **Fil-C vs. clang 성능 그래프** 공개 - 약 9000개 암호화 관련 마이크로벤치마크 결과 - Fil-C로 컴파일된 코드는 clang 대비 1~4배의 사이클 소모 ### Fil-C 설치 및 빌드 - root 권한으로 필요한 패키지 설치 후, 비특권 사용자 `filc`로 빌드 수행 - Fil-C 소스는 glibc 및 여러 고수준 라이브러리·애플리케이션을 포함 - 빌드 명령: `time ./build_all_fast_glibc.sh` - musl도 선택 가능하지만 일부 패키지(attr, elfutils, sed, vim 등)와 **비호환성** 존재 - 빌드 중 메모리 부족 발생 시 스왑 공간을 36GB로 확장해 해결 - 최대 약 19GB 스왑과 12GB RAM 사용 - 대형 서버(128코어, 512GB RAM)에서는 Fil-C 빌드 8분, musl 빌드 6분 소요 ### 추가 라이브러리 및 애플리케이션 빌드 - Fil-C에는 여러 라이브러리와 애플리케이션을 빌드하는 **build_all_slow.sh** 포함 - 이를 병렬화한 **build-parallel-20251023.py** 스크립트 작성 - 오류 발생 시 중단하지 않고 전체 빌드 진행 - 병렬 빌드로 시간 단축 가능 - phoenix 시스템에서 61개 타깃 중 60개 성공 (실시간 101분) - **libcap**만 빌드 실패 (liblto_plugin.so 로드 오류) - **util-linux**는 syscall 관련 수정 필요 - 나머지 주요 패키지(attr, bash, curl, openssl, vim 등)는 문제 없이 빌드 완료 ### 추가 테스트된 라이브러리 및 애플리케이션 - **boost 1.89.0**: 대부분 정상 작동, 일부 vfork 관련 수정 필요 - **cdb-20251021**: 정상 작동, 인위적 OOM 테스트에서 오류 메시지 차이 - **libcpucycles, libgc(gshim 대체), libntruprime, lpeg, luv** 등 정상 빌드 및 테스트 - **mutt, tig, w3m** 등 주요 CLI 애플리케이션도 정상 동작 확인 ### Debian 통합 (Filian) - Debian의 다중 아키텍처 구조를 활용해 **Fil-C 전용 ABI(amd64fil0)** 추가 - 예: `apt install bash:amd64fil0`로 Fil-C 컴파일 버전 설치 가능 - Fil-C는 `/usr/include` 대신 자체 디렉터리를 사용해 **헤더 파일 경로 불일치 문제** 발생 - filian-install-compiler 스크립트에서 이를 Debian 표준 경로로 조정 - Debian 빌드 도구(dpdk-buildpackage, sbuild 등)에 Fil-C 아키텍처 인식 추가 - `/usr/share/dpkg/cputable`, `config.sub` 등 수정 - Fil-C 및 표준 라이브러리를 `/usr/libexec/fil/amd64` 경로에 배치 - `filcc`, `fil++` 명령을 시스템 전역에서 사용 가능 ### Debian 패키지 빌드 예시 - `fillet` 헬퍼 스크립트로 Debian 소스 패키지의 심볼 및 설치 경로 조정 - `tinycdb` 패키지를 Fil-C로 빌드한 결과, **amd64fil0 전용 .deb 패키지 3개 생성** - 설치 후 `nm`, `ldd` 명령으로 Fil-C 심볼(`pizlonated_`) 및 라이브러리 경로 확인 - 실행 시 Fil-C 런타임 보호 기능 작동 확인 (“memory safety” 위반 차단 메시지 출력) ### 추가 Debian 패키지 빌드 - **libc-dev**: 의존성 해결용 가짜 패키지 생성 - **ncurses**: Fil-C로 빌드 후 설치 가능 - **libmd**: 아키텍처 간 버전 불일치로 재컴파일 필요 - **readline**: 헤더 경로 심볼릭 링크 필요 - **lua5.4**: readline 의존성 해결 후 정상 작동 ### 결론 - Fil-C는 **메모리 안전성 강화와 기존 C/C++ 생태계 호환성**을 동시에 달성하려는 시도 - Debian 환경에서의 **패키지 빌드 및 통합 가능성**이 입증됨 - 일부 빌드 스크립트와 헤더 경로 조정이 필요하지만, **대부분의 주요 오픈소스 패키지와 호환성 확보** ## Comments ### Comment 45805 - Author: neo - Created: 2025-11-03T09:47:10+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45788040) - 링크된 [벤치마크](https://cr.yp.to/2025/20251028-filcc-vs-clang.html)를 보면 Fil-C가 C보다 더 빠르게 보이는 경우가 있음 아마 **마이크로벤치마크의 변동성** 때문일 거라 생각하지만, 일부 결과는 너무 빠르게 보여서 **정확성 문제**가 있는지 궁금해짐 - 작성자가 Fil-C에 상당히 감명받아서 전체 Debian 시스템을 Fil-C로 재빌드하려는 시도를 하고 있음 이를 위해 **GC shim 라이브러리**와 빌드 스크립트를 만들어 공유하고 있음 - 서버에 swap이 12GB밖에 없어서 Fil-C 컴파일 중 메모리 부족으로 여러 번 재시작했음 swap을 36GB로 늘리자 정상적으로 빌드되었고, 최대 **19GB swap + 12GB RAM**을 사용했음 128코어, 512GB RAM 서버에서는 Fil-C 빌드에 8분, musl에 6분이 걸렸음 Fil-C가 **정적 분석**을 많이 수행하는 듯함 - 그건 LLVM+Clang 자체를 빌드하는 과정일 가능성이 높음 - 새로 공개된 64비트 버전의 **cdb**가 엑사바이트급 데이터베이스를 지원한다는 점이 흥미로움 [cdb.cr.yp.to](https://cdb.cr.yp.to)에서 확인 가능하며, 새 cdb 서브도메인이 **pqconnect**를 사용한다고 언급됨 - 실제로는 cdb.cr.yp.to에 NS 레코드가 없어서 DNSCurve가 작동하는 구조임 pqconnect는 HTTP(S) 연결 단계에서 사용되고, 둘 다 **DNS에 공개키를 인코딩**하지만 역할이 다름 pqconnect는 CurveCP처럼 **CNAME에 공개키를 포함**함 - RFC1034에 따르면 cdb.cr.yp.to는 cr.yp.to와 yp.to의 **하위 도메인(subdomain)** 으로 볼 수 있음 다만 pq1 부분은 공개키가 아니라 서버의 장기 공개키 해시임 - pqconnect 사용은 예전부터 있었지만, cdb.cr.yp.to의 CNAME은 **10월 21일경 새로 추가된 것**으로 보임 Fil-C 관련 노트는 3일 전에 제출되었음 [관련 스레드](https://news.ycombinator.com/item?id=45765718) - 참고로 11일 전에도 관련 논의가 있었음 [이전 토론 링크](https://news.ycombinator.com/item?id=45663435) - 멋진 프로젝트라고 생각함 목표는 C/C++ 프로그램 대부분이 **Rust로 다시 작성할 필요 없이** 안전하게 실행되도록 하는 것 같음 Epic Games가 어떻게 관련되는지도 궁금함 - Fil-C는 **가비지 컬렉션 기반 언어**라서 C보다 훨씬 느림 새로운 코드를 작성하기보다는 **WASM 샌드박싱**처럼 기존 코드를 안전하게 감싸는 용도로 적합함 다만 Fil-C는 **크래시를 더 정확히** 잡아냄 - Phil의 작업이 드디어 **정당한 인정을 받는 것 같아** 기쁨 Rust의 unsafe 모드에도 참고할 만한 점이 있을 듯함 특히 Fil-C로 컴파일된 의존성을 **정적 링크**하는 방식은 흥미로움 - 하지만 Fil-C는 현재 **FFI를 지원하지 않음** 포인터 추적을 위해 프로그램 전체를 Fil-C가 통제해야 하므로 FFI는 구조적으로 맞지 않음 - Fil-C 관련 주요 스레드들을 정리함 예: [Fil-C: A memory-safe C implementation](https://news.ycombinator.com/item?id=45735877), [Safepoints and Fil-C](https://news.ycombinator.com/item?id=45258029), [Fil’s Unbelievable Garbage Collector](https://news.ycombinator.com/item?id=45133938) 등 2024~2025년 사이의 **메모리 안전성 논의**가 이어지고 있음 - Fil-C가 무엇인지 모르는 사람들을 위해 요약함 Fil-C는 **C/C++과 호환되는 메모리 안전 구현체**로, 대부분의 코드가 거의 수정 없이 컴파일됨 모든 메모리 오류는 **panic으로 감지**되며, **동시 GC와 InvisiCaps**로 안전성을 확보함 [공식 사이트](https://fil-c.org/)에서 자세한 설명을 볼 수 있음 - Fil-C를 사용하려면 런타임에 **Garbage Collector를 수용해야 함** - build_all_fast_glibc.sh 스크립트가 31GB 메모리를 요구한다는 점이 놀라움 이유를 알고 싶고, 직접 Fil-C를 시도해보고 싶음 - 그건 **LLVM 빌드와 링크 과정이 무겁기 때문**임 - 유명한 암호학자가 bash와 curl을 사용하는 모습이 흥미로움 - 사실 **curl | bash**는 괜찮은 경우도 많음 [관련 글](https://medium.com/@ewindisch/curl-bash-a-victimless-crime-d6676eb607c9)