실행 파일을 SQLite 데이터베이스로: ELF를 대체하는 SELF

Executable Is a SQLite Database

▲ 545setheron106 HN 토론
실행 파일을 SQLite 데이터베이스로: ELF를 대체하는 SELF

저자는 ELF 파일 형식을 SQLite 데이터베이스로 대체하는 실험적인 실행 파일 형식 'SELF'를 소개합니다. SELF는 ELF의 헤더, 세그먼트, 심볼 테이블을 SQLite 테이블로 표현하여, 기존의 readelf, nm, ldd 같은 도구들이 SQL 쿼리로 대체됩니다. 이 접근 방식은 ELF가 이미 데이터베이스의 원시적인 구현임을 드러내며, strip이나 patchelf 같은 수정 작업이 트랜잭션으로 간단해집니다. 또한 binfmt_misc를 통해 실행 가능하며, 동적 링킹도 SQL로 처리할 수 있는 프로토타입을 제시합니다. 벤치마크 결과, 크기는 최적화 시 ELF와 비슷하지만 실행 속도는 약간 느립니다.

ELF는 이미 데이터베이스다. 다만 많은 데이터베이스 프리미티브를 손수 구현하고 있을 뿐이다.
원문 읽기 →HN 토론RSS

HN 토론

106
  1. andai

    이 글 전체가 환상적이지만, 이미 시작부터 SQLite 가상 테이블 기능이 제 정신을 날려버리고 있네요.

    https://www.sqlite.org/vtablist.html

    파일 시스템(또는 다른 무엇이든)을 SQL 데이터베이스로 "마운트"할 수 있다니, 대체 뭐죠? 정말 놀랍습니다.

    이건 엄청 유용할 것 같아요.

  2. setheron

    저는 댓글들을 즐기고 있습니다.

    제가 이 아이디어를 학계에 짧은 논문으로 발표했을 때, 피드백은 그렇게 호의적이지 않았거든요.

  3. inigyou

    > 저는 뭔가 거슬리는 것을 깨달았습니다. ELF는 이미 데이터베이스입니다.

    더 넓게 적용하면: 모든 데이터의 기반은 이미 데이터베이스입니다(그게 복합어의 의미니까요). sqlite나 postgres 같은 프로그램들은 그 사용이 너무 보편화되어 구어적으로 데이터베이스라고 불리기 전까지는 더 정확한 용어인 "관계형 데이터베이스 관리 소프트웨어" 또는 "RDBMS"라고 불렸습니다.

    최초의 데이터베이스 구조는 하드 드라이브의 각 기하학적 섹터가 레코드이고 각 헤드가 열(column)인 것과 더 비슷했습니다. 이것은 천공 카드 작업 흐름을 자기 디스크로 직접 번역한 것이었습니다.

  4. XJ6w9dTdM

    네!

    이것은 한동안 제 마음속에 있었던 생각입니다. 그리고 다른 댓글 작성자들이 언급했듯이, 파일에 (자기 수정 가능한) Lisp 이미지, 내장 가상 파일 시스템, 그리고 애플리케이션이 (런타임에 수정 가능한) 추가 테이블로 사용하고 싶은 무엇이든 포함하는 것은 훌륭할 것입니다.

    SQLite 동적 링크가 기본적으로 ELF 동적 링크와 호환된다는 점이 매우 인상적입니다. 잘 만들어진다면, 저자가 제안한 것처럼 대부분의 AppImage 사용을 훨씬 더 효율적인 형식으로 대체할 수 있을 것이라고 상상할 수 있습니다.

    저자가 텍스트 페이지를 직접 mmap할 수 없고 어쨌든 복사해야 한다고 언급했으니, SQLite blob 내에서 섹션 내용을 압축하는 옵션은 어떨까요?

    SQLite 실행 파일을 진정으로 독특하게 만들 두 가지 확장 기능을 생각하고 있었습니다.

    첫째, 함수와 훅을 더 직접적으로 패치할 수 있게 해주는 링크 확장으로, 매우 강력한 플러그인 시스템을 가능하게 하는 것입니다. 호스트 SQLite가 확장 가능하다고 정의한 일부 심볼에 대해 플러그인 SQLite가 BEFORE/AFTER/REPLACE 훅을 정의하는 것을 상상해 보세요.

    둘째, 런타임 시 재링크. 이는 애플리케이션 작성자의 협력이 필요할 것입니다. 어디에서나 그렇게 할 수는 없겠지만, db를 편집하여 런타임에 종속성을 변경하거나 플러그인을 로드하고, 인터프리터가 요청 시/백그라운드에서 자동으로 매핑하는 것을 상상해 보세요. 그러면 다음에 웹 서버가 accept()를 호출할 때, 새로운 버전의 처리 함수를 호출하게 됩니다.

  5. djoldman

    > 형식 자체는 매우 간결하며, 디스크 공간과 네트워크 대역폭이 극도로 부족했던 세상을 위해 설계되었습니다. 형식을 수정하는 것은 어렵습니다. 너무 빽빽하게 채워져 있어서 섹션을 0으로 채우고 새로 추가해야 하는 경우가 많습니다. 또한 자기 설명적인 스키마가 없습니다. ELF 자체는 관례에 따라 특정 방식으로 해석되는 데이터 섹션을 지원하는 매우 일반적인 형식이지만, 형식이 이를 강제하지는 않습니다.

    이것은 다음과 같은 훌륭한 사용 사례처럼 들립니다:

    1. ELF 파일을 SELF 파일로

    2. SELF 파일 수정

    3. SELF 파일을 ELF 파일로

  6. garganzol

    복사된 메모리와 매핑된 메모리의 상황은 이 실험에서 유일한 문제점입니다. 그 외에는 파일 형식 통일이 큰 진전이 될 것입니다. Windows(및 일부 오래된 Unix 시스템)에서 사용되는 PE/COFF 실행 파일 형식도 관계형 데이터베이스입니다. .NET 어셈블리 형식도 마찬가지입니다. 그것도 관계형 데이터베이스입니다. 바퀴는 계속해서 재발명되고 있습니다.

  7. catlifeonmars

    객체 파일이 관계형 데이터베이스로 간주될 수 있다는 것은 이해할 수 있습니다. 그런데 왜 SQLite인가요? 객체 파일 위에서 가상 테이블 추상화를 사용하는 SQL 쿼리 엔진은 왜 안 되나요? 쿼리 엔진의 일부를 제외하고 SQLite 기능의 대부분이 어떻게 적용될 수 있는지 잘 모르겠습니다.

    저자가 객체 파일에 스키마 메타데이터를 포함하는 것에 대한 근거를 제시하려 한다면, 다시 말하지만 왜 SQLite인가요? 이것은 새로운 개선된 객체 파일 형식이 어떤 모습일지에 대한 진지한 탐구라기보다는, 자신이 가장 좋아하는 망치(아주 유용한 망치라고 말할 수 있겠지만)를 사용할 곳을 찾는 사람처럼 보입니다.

    (그리고 그것은 완전히 괜찮습니다)

  8. unified101

    이것은 충분히 나아가지 않았다고 생각합니다! 실제 앱 스토어를 파일 자체로 만드세요. 그래서 그것은 살아있는 애플리케이션이 되고 파일은 당신이 그것을 사용하는 방식에 따라 끊임없이 업데이트됩니다. 그것을 복사하면 데이터도 함께 가져갈 수 있습니다.

    더 깊이 들어가 봅시다. 그것은 웹서버 앱 + 서버 코드 + 애플리케이션 코드 + db이므로, pocketbase++이면서 동시에 배포 대상이기도 합니다.

    그런 다음 APE와 같은 시스템과 결합하면, 같은 파일이 모든 플랫폼에서 로드되고 저장됩니다. 사악한 웃음.

    정말 멋진 해킹입니다! 저자에게 경의를 표합니다.

이 날의 다른 글

2026-08-24