QEMU.js: 이제 WASM으로 심각해졌습니다.

옛날 옛적에 나는 재미로 결정했습니다 과정의 가역성을 증명하다 기계 코드에서 JavaScript(보다 정확하게는 Asm.js)를 생성하는 방법을 알아보세요. 실험을 위해 QEMU가 선택되었고 얼마 후 Habr에 대한 기사가 작성되었습니다. 댓글에서 나는 WebAssembly에서 프로젝트를 다시 만들고 심지어 스스로 그만두라는 조언을 받았습니다. 거의 끝났다 왠지 프로젝트가 마음에 들지 않았습니다 ... 작업이 진행 중이었지만 매우 느리게 진행되었으며 최근에 해당 기사가 나타났습니다. 논평 "그럼 어떻게 끝났나요?"라는 주제에 대해 내 자세한 답변에 “이건 기사 같다”는 말을 들었다. 글쎄, 가능하다면 기사가있을 것입니다. 어쩌면 누군가가 유용하다고 생각할 수도 있습니다. 여기에서 독자는 QEMU 코드 생성 백엔드 설계에 대한 몇 가지 사실과 웹 애플리케이션용 Just-in-Time 컴파일러를 작성하는 방법을 배우게 됩니다.

작업

QEMU를 JavaScript로 "어떻게든" 포팅하는 방법을 이미 배웠기 때문에 이번에는 현명하게 수행하고 오래된 실수를 반복하지 않기로 결정했습니다.

오류 번호 XNUMX: 포인트 릴리스에서 분기

나의 첫 번째 실수는 업스트림 버전 2.4.1에서 내 버전을 포크한 것이었습니다. 그렇다면 그것은 좋은 생각인 것 같았습니다. 포인트 릴리스가 존재한다면 아마도 단순한 2.4보다 더 안정적일 것입니다. master. 그리고 내 버그를 꽤 많이 추가할 계획이었기 때문에 다른 사람의 버그는 전혀 필요하지 않았습니다. 아마도 그렇게되었을 것입니다. 그런데 문제는 QEMU가 가만히 있지 않고 어느 순간에는 생성된 코드를 10% 최적화하겠다고 발표하기도 했다. 여기서 우리는 여담을 만들 필요가 있습니다: QEMU.js의 단일 스레드 특성과 원래 QEMU가 멀티 스레딩의 부재를 의미하지 않는다는 사실(즉, 관련되지 않은 여러 코드 경로를 동시에 작동하는 기능 및 단순히 "모든 커널을 사용하는 것"이 ​​아니라 외부에서 호출할 수 있도록 스레드의 주요 기능을 "해제"해야 했습니다. 이로 인해 합병 중에 몇 가지 자연적인 문제가 발생했습니다. 그러나 지점에서 일부 변경된 사실은 master내 코드를 병합하려고 시도한 코드도 포인트 릴리스에서 체리 선택되었으므로(따라서 내 브랜치에서도) 편의성이 추가되지 않았을 것입니다.

일반적으로 저는 프로토타입을 버리고 부품용으로 분해하고 더 새로운 것을 기반으로 처음부터 새 버전을 만드는 것이 여전히 합리적이라고 결정했습니다. master.

두 번째 실수: TLP 방법론

본질적으로 이것은 실수가 아니며 일반적으로 "어디로 어떻게 이동할 것인가?"와 "우리가 거기에 도착할 것인가?"에 대한 완전한 오해의 조건에서 프로젝트를 만드는 기능일뿐입니다. 이러한 조건에서는 서투른 프로그래밍 정당한 선택이었지만 당연히 불필요하게 반복하고 싶지 않았습니다. 이번에는 원자적 커밋, 의식적인 코드 변경(Wikiquote에 따르면 Linus Torvalds가 누군가에 대해 말한 것처럼 "컴파일할 때까지 (경고와 함께) 임의의 문자를 연결"하지 않음) 등을 현명하게 수행하고 싶었습니다.

세 번째 실수: 포드를 모르고 물에 들어가는 것

아직 이 문제를 완전히 없애지는 못했지만 이제 저항이 가장 적은 길을 전혀 따르지 않고 "성인으로서" 하기로 결정했습니다. 즉, TCG 백엔드를 처음부터 작성하기로 했습니다. 나중에 이렇게 말해야 합니다. "물론 느리지만 모든 것을 제어할 수는 없습니다. 그게 TCI가 작성된 방식입니다..." 더욱이 이것은 처음에는 분명한 해결책처럼 보였습니다. 바이너리 코드를 생성합니다. 그들은 “겐트가 모였다”고 말하듯이у, 그러나 그 코드는 아닙니다.”: 코드는 물론 바이너리이지만 제어가 단순히 코드로 전송될 수는 없습니다. 컴파일을 위해 명시적으로 브라우저에 푸시되어야 하며 JS 세계의 특정 객체가 생성되어야 합니다. 어딘가에 저장됩니다. 그러나 일반적인 RISC 아키텍처에서 내가 이해하는 한 일반적인 상황은 재생성된 코드에 대한 명령 캐시를 명시적으로 재설정해야 하는 것입니다. 이것이 우리에게 필요한 것이 아니라면 어쨌든 종료됩니다. 게다가 지난번 시도에서 제어가 번역 블록의 중간으로 전달되지 않는 것 같아서 오프셋에서 해석된 바이트코드가 실제로 필요하지 않고 TB의 함수에서 간단히 생성할 수 있다는 것을 알게 되었습니다. .

그들이 와서 발로 찼다

XNUMX월에 코드를 다시 작성하기 시작했지만 눈에 띄지 않게 마법 같은 일이 일어났습니다. 일반적으로 GitHub의 편지는 이슈 및 풀 요청에 대한 응답에 대한 알림으로 도착하지만 여기서는 갑자기 스레드에서 언급 Qemu 백엔드로서의 Binaryen 맥락에서 "그 사람이 그런 짓을 했으니 뭐라고 말할지도 몰라요." 우리는 Emscripten의 관련 라이브러리를 사용하는 것에 대해 이야기하고 있었습니다. 바이너리엔 WASM JIT를 생성합니다. 글쎄요, 거기에는 Apache 2.0 라이센스가 있고 QEMU는 전체적으로 GPLv2에 따라 배포되며 호환성이 좋지 않다고 말했습니다. 갑자기 라이센스가 가능하다는 것이 밝혀졌습니다. 어떻게든 고쳐 (모르겠어요: 변경할 수도 있고, 이중 라이센스일 수도 있고, 다른 것일 수도 있습니다...). 물론 이것은 나를 행복하게 만들었습니다. 왜냐하면 그때까지 나는 이미 자세히 살펴 봤기 때문입니다. 바이너리 형식 WebAssembly와 저는 왠지 슬프고 이해할 수 없었습니다. 또한 전환 그래프를 사용하여 기본 블록을 집어삼키고, 바이트코드를 생성하고, 필요한 경우 인터프리터 자체에서 실행하는 라이브러리도 있었습니다.

그 다음에는 더 많은 것이있었습니다 편지 QEMU 메일링 리스트에 있지만 이는 "어쨌든 누가 필요합니까?"라는 질문에 관한 것입니다. 그리고 그건 갑자기, 그것이 필요하다는 것이 밝혀졌습니다. 최소한 어느 정도 빠르게 작동한다면 이러한 사용 가능성을 함께 긁어낼 수 있습니다.

• 전혀 설치하지 않고 교육적인 것을 시작하기
• 소문에 따르면 즉석에서 코드를 생성할 수 있는 유일한 애플리케이션은 JS 엔진뿐이라는 소문이 있는 iOS의 가상화(사실인가요?)
• 미니 OS 시연 - 단일 플로피, 내장, 모든 종류의 펌웨어 등...

브라우저 런타임 기능

이미 말했듯이 QEMU는 멀티스레딩과 연결되어 있지만 브라우저에는 멀티스레딩이 없습니다. 글쎄요, 아니요... 처음에는 전혀 존재하지 않았으나 나중에 WebWorkers가 나타났습니다. 제가 아는 한 이것은 메시지 전달을 기반으로 한 멀티스레딩입니다. 공유변수 없이. 당연히 이는 공유 메모리 모델을 기반으로 기존 코드를 이식할 때 심각한 문제를 야기합니다. 그러다가 대중의 압력을 받아 이 이름으로도 시행되었습니다. SharedArrayBuffers. 점차적으로 도입되어 다양한 브라우저에서 출시를 축하한 다음 새해를 축하하고 멜트다운... 그 후 그들은 시간 측정이 대략적이거나 대략적이라는 결론에 도달했지만 공유 메모리와 스레드가 카운터를 증가시키는 경우 모두 동일합니다. 꽤 정확하게 작동할 거야. 그래서 우리는 공유 메모리로 멀티스레딩을 비활성화했습니다. 나중에 다시 켠 것 같지만, 첫 번째 실험에서 분명해졌듯이, 그것 없이도 생명이 있고, 만약 그렇다면 멀티스레딩에 의존하지 않고 해보도록 하겠습니다.

두 번째 기능은 스택을 사용하여 낮은 수준의 조작이 불가능하다는 것입니다. 단순히 현재 컨텍스트를 가져와서 저장하고 새 스택이 있는 새 컨텍스트로 전환할 수는 없습니다. 호출 스택은 JS 가상 머신에 의해 관리됩니다. 이전 흐름을 완전히 수동으로 관리하기로 결정했는데 문제가 무엇인 것 같습니까? 사실 QEMU의 블록 I/O는 코루틴을 통해 구현되며, 여기서 낮은 수준의 스택 조작이 유용합니다. 다행스럽게도 Emscipten에는 이미 두 가지 비동기 작업 메커니즘이 포함되어 있습니다. 비동기화 и 통역사. 첫 번째는 생성된 JavaScript 코드의 상당한 부풀림을 통해 작동하며 더 이상 지원되지 않습니다. 두 번째는 현재의 "올바른 방법"이며 기본 인터프리터의 바이트코드 생성을 통해 작동합니다. 물론 천천히 작동하지만 코드가 부풀어오르지는 않습니다. 사실, 이 메커니즘에 대한 코루틴 지원은 독립적으로 제공되어야 했습니다(Asyncify용으로 작성된 코루틴이 이미 있었고 Emterpreter용으로 거의 동일한 API 구현이 있었기 때문에 연결하기만 하면 되었습니다).

현재로서는 코드를 WASM으로 컴파일하고 Emterpreter를 사용하여 해석한 코드로 분할하지 못했기 때문에 블록 장치는 아직 작동하지 않습니다(다음 시리즈에서 말하는 것처럼...). 즉, 결국에는 다음과 같은 재미있는 레이어를 얻게 됩니다.

• 블록 I/O를 해석합니다. 글쎄요, 기본 성능으로 에뮬레이트된 NVMe를 기대하셨나요? 🙂
• 정적으로 컴파일된 기본 QEMU 코드(변환기, 기타 에뮬레이트된 장치 등)
• 동적으로 컴파일된 게스트 코드를 WASM으로

QEMU 소스의 특징

이미 짐작하셨겠지만, 게스트 아키텍처를 에뮬레이션하기 위한 코드와 호스트 기계 명령어를 생성하기 위한 코드는 QEMU에서 분리되어 있습니다. 실제로는 조금 더 까다롭습니다.

• 게스트 아키텍처가 있습니다
• 이 가속기즉, Linux의 하드웨어 가상화를 위한 KVM(서로 호환되는 게스트 및 호스트 시스템용), 어디서나 JIT 코드 생성을 위한 TCG입니다. QEMU 2.9부터 Windows에서 HAXM 하드웨어 가상화 표준에 대한 지원이 나타났습니다(세부 사항)
• TCG를 사용하고 하드웨어 가상화를 사용하지 않는 경우 각 호스트 아키텍처와 범용 인터프리터에 대해 별도의 코드 생성을 지원합니다.
• ... 그리고 이 모든 것 - 에뮬레이트된 주변 장치, 사용자 인터페이스, 마이그레이션, 기록 재생 등

그런데 알고 계셨나요? QEMU는 전체 컴퓨터뿐만 아니라 바이너리 계측용 AFL 퍼저 등에서 사용되는 호스트 커널의 별도 사용자 프로세스용 프로세서도 에뮬레이션할 수 있습니다. 아마도 누군가가 이 QEMU 작동 모드를 JS로 이식하고 싶어할까요? 😉

대부분의 오랜 무료 소프트웨어와 마찬가지로 QEMU는 호출을 통해 구축됩니다. configure и make. TCG 백엔드, 스레드 구현 등을 추가하기로 결정했다고 가정해 보겠습니다. Autoconf와 통신할 가능성이 있다고 서두르지 말고 행복하거나 겁을 먹거나(해당하는 경우 밑줄을 긋습니다) - 사실, configure QEMU는 분명히 자체 작성되었으며 어떤 것에서도 생성되지 않습니다.

WebAssembly

그렇다면 WebAssembly(일명 WASM)라는 것은 무엇일까요? 이는 Asm.js를 대체하며 더 이상 유효한 JavaScript 코드인 척하지 않습니다. 반대로 순전히 바이너리이고 최적화되어 있으며 단순히 정수를 쓰는 것조차 그리 간단하지 않습니다. 압축을 위해 다음 형식으로 저장됩니다. LEB128.

Asm.js의 재루핑 알고리즘에 대해 들어보셨을 것입니다. 이는 JS 엔진이 설계된 "고수준" 흐름 제어 명령(즉, if-then-else, 루프 등)을 복원한 것입니다. 프로세서에 의해 실행되는 기계어 코드에 더 가까운 낮은 수준의 LLVM IR. 당연히 QEMU의 중간 표현은 두 번째에 가깝습니다. 여기 바이트코드, 고통의 끝인 것 같습니다... 그리고 블록, if-then-else 및 루프가 있습니다!..

이것이 Binaryen이 유용한 또 다른 이유입니다. WASM에 저장되는 것과 유사한 상위 수준 블록을 자연스럽게 수용할 수 있기 때문입니다. 그러나 기본 블록과 그 사이의 전환 그래프에서 코드를 생성할 수도 있습니다. 글쎄요, 저는 이미 편리한 C/C++ API 뒤에 WebAssembly 저장 형식이 숨겨져 있다고 말했습니다.

TCG(작은 코드 생성기)

TCG 원래는 C 컴파일러의 백엔드 그런 다음 분명히 GCC와의 경쟁을 견딜 수 없었지만 결국 QEMU에서 호스트 플랫폼의 코드 생성 메커니즘으로 자리를 잡았습니다. 인터프리터에 의해 즉시 실행되는 일부 추상 바이트코드를 생성하는 TCG 백엔드도 있지만 이번에는 사용하지 않기로 결정했습니다. 그러나 QEMU에서는 이미 다음 기능을 통해 생성된 TB로의 전환이 가능하다는 사실이 있습니다. tcg_qemu_tb_exec, 그것은 나에게 매우 유용한 것으로 판명되었습니다.

QEMU에 새로운 TCG 백엔드를 추가하려면 하위 디렉터리를 생성해야 합니다. tcg/<имя архитектуры> (이 경우, tcg/binaryen), 여기에는 두 개의 파일이 포함되어 있습니다. tcg-target.h и tcg-target.inc.c и 처방하다 그것은 모든 것입니다 configure. 거기에 다른 파일을 넣을 수도 있지만, 이 두 파일의 이름에서 짐작할 수 있듯이 둘 다 어딘가에 포함될 것입니다. 하나는 일반 헤더 파일로(다음에 포함되어 있습니다) tcg/tcg.h, 해당 파일은 이미 디렉토리의 다른 파일에 있습니다. tcg, accel 뿐만 아니라), 다른 하나는 코드 조각으로만 tcg/tcg.c, 그러나 정적 기능에 액세스할 수 있습니다.

그것이 어떻게 작동하는지 자세히 조사하는 데 너무 많은 시간을 소비하기로 결정하고 다른 백엔드 구현에서 이 두 파일의 "골격"을 복사하여 이를 라이센스 헤더에 솔직하게 표시했습니다.

파일 tcg-target.h 주로 형식의 설정이 포함되어 있습니다. #define-에스:

• 대상 아키텍처에 레지스터 수와 너비가 얼마나 됩니까?(우리는 원하는 만큼 많이 가지고 있습니다. 문제는 "완전한 대상" 아키텍처에서 브라우저에 의해 더 효율적인 코드로 생성되는 것이 무엇인지에 관한 것입니다. ...)
• 호스트 명령어 정렬: x86 및 TCI에서도 명령어는 전혀 정렬되지 않지만 코드 버퍼에 명령어가 아닌 Binaryen 라이브러리 구조에 대한 포인터를 넣을 것이므로 다음과 같이 말할 것입니다. 4 바이트
• 백엔드가 생성할 수 있는 선택적 명령 - Binaryen에서 찾은 모든 것을 포함하고 가속기가 나머지를 더 간단한 명령으로 나누도록 합니다.
• 백엔드에서 요청한 TLB 캐시의 대략적인 크기는 얼마입니까? 사실 QEMU에서는 모든 것이 심각합니다. 게스트 MMU를 고려하여 로드/저장을 수행하는 도우미 기능이 있지만(지금 이것이 없으면 어디에 있을까요?) 번역 캐시를 구조 형태로 저장합니다. 이를 처리하는 것은 방송 블록에 직접 삽입하는 것이 편리합니다. 문제는 이 구조의 어떤 오프셋이 작고 빠른 명령 시퀀스에 의해 가장 효율적으로 처리되는지입니다.
• 여기서는 하나 또는 두 개의 예약된 레지스터의 목적을 조정할 수 있고, 함수를 통해 TB 호출을 활성화하고 선택적으로 두 개의 작은 레지스터를 설명할 수 있습니다. inline-다음과 같은 기능 flush_icache_range (그러나 이것은 우리의 경우가 아니다)

파일 tcg-target.inc.c물론, 일반적으로 크기가 훨씬 크며 몇 가지 필수 기능을 포함합니다.

• 어떤 명령어가 어떤 피연산자에서 작동할 수 있는지에 대한 제한을 포함한 초기화. 다른 백엔드에서 내가 노골적으로 복사했습니다.
• 하나의 내부 바이트코드 명령어를 취하는 함수
• 여기에 보조 기능을 넣을 수도 있고, 다음의 정적 기능을 사용할 수도 있습니다. tcg/tcg.c

나 자신을 위해 다음 전략을 선택했습니다. 다음 번역 블록의 첫 번째 단어에 XNUMX개의 포인터를 적었습니다. 시작 표시(근처의 특정 값) 0xFFFFFFFFTB의 현재 상태), 컨텍스트, 생성된 모듈, 디버깅을 위한 매직 넘버를 결정했습니다. 처음에는 마크가 다음 위치에 배치되었습니다. 0xFFFFFFFF - n어디에서 n - 작은 양수이며, 인터프리터를 통해 실행될 때마다 1씩 증가합니다. 0xFFFFFFFE, 컴파일이 이루어지고 모듈이 함수 테이블에 저장되고 작은 "실행기"로 가져와서 실행이 시작되었습니다. tcg_qemu_tb_exec, 모듈이 QEMU 메모리에서 제거되었습니다.

고전을 의역하면 "Crutch, 프로거의 심장을 위한 이 소리에 얼마나 많은 것이 얽혀 있는지..."입니다. 그러나 어딘가에서 기억이 새고 있었다. 게다가 QEMU가 관리하는 메모리였습니다! 다음 명령(즉, 포인터)을 작성할 때 이전에 이 위치에 링크가 있던 명령을 삭제하는 코드가 있었지만 이는 도움이 되지 않았습니다. 실제로 가장 간단한 경우 QEMU는 시작 시 메모리를 할당하고 거기에 생성된 코드를 작성합니다. 버퍼가 부족해지면 코드가 삭제되고 그 자리에 다음 코드가 작성되기 시작합니다.

코드를 연구한 후 매직 넘버를 사용한 트릭을 사용하면 첫 번째 단계에서 초기화되지 않은 버퍼에서 잘못된 것을 해제하여 힙 파괴에 실패하지 않도록 할 수 있다는 것을 깨달았습니다. 하지만 나중에 내 기능을 우회하기 위해 버퍼를 다시 작성하는 사람은 누구입니까? Emscripten 개발자의 조언에 따르면 문제가 발생했을 때 결과 코드를 기본 애플리케이션으로 다시 포팅하고 거기에 Mozilla Record-Replay를 설정했습니다... 일반적으로 결국 저는 간단한 것을 깨달았습니다. 각 블록에 대해 ㅏ struct TranslationBlock 설명과 함께. 어디인지 추측해 보세요... 맞습니다. 버퍼의 블록 바로 앞입니다. 이것을 깨달은 나는 목발 사용을 (적어도 일부) 그만두기로 결정하고 매직 넘버를 버리고 남은 단어를 struct TranslationBlock, 번역 캐시가 재설정될 때 빠르게 탐색하고 메모리를 확보할 수 있는 단일 연결 목록을 생성합니다.

일부 목발은 남아 있습니다. 예를 들어 코드 버퍼에 표시된 포인터 - 그 중 일부는 단순히 BinaryenExpressionRef즉, 생성된 기본 블록에 선형적으로 넣어야 할 표현식을 보면, 일부는 BB 간 전환 조건, 일부는 어디로 가야 할지에 대한 부분입니다. 자, 조건에 따라 연결해야 하는 리루퍼용 블록은 이미 준비되어 있습니다. 이를 구별하기 위해 모두 최소 XNUMX바이트로 정렬되어 있다는 가정이 사용됩니다. 따라서 레이블에 최하위 XNUMX비트를 안전하게 사용할 수 있으며 필요한 경우 제거하는 것만 기억하면 됩니다. 그런데 이러한 레이블은 이미 QEMU에서 사용되어 TCG 루프를 종료하는 이유를 나타냅니다.

바이너리 사용하기

WebAssembly의 모듈에는 함수가 포함되어 있으며 각 함수에는 표현식인 본문이 포함되어 있습니다. 표현식은 단항 및 이진 연산, 다른 표현식 목록으로 구성된 블록, 제어 흐름 등입니다. 이미 말했듯이 여기서 제어 흐름은 상위 수준 분기, 루프, 함수 호출 등으로 정확하게 구성됩니다. 함수에 대한 인수는 스택에 전달되지 않지만 JS와 마찬가지로 명시적으로 전달됩니다. 전역 변수도 있지만 사용해본 적이 없어서 설명하지 않겠습니다.

함수에는 int32 / int64 / float / double 유형의 XNUMX부터 번호가 매겨진 지역 변수도 있습니다. 이 경우 처음 n개의 지역 변수는 함수에 전달된 인수입니다. 제어 흐름 측면에서 여기에 있는 모든 것이 완전히 낮은 수준은 아니지만 정수에는 여전히 "부호 있는/부호 없는" 속성이 없습니다. 숫자의 동작 방식은 연산 코드에 따라 다릅니다.

일반적으로 Binaryen은 다음을 제공합니다. 간단한 C-API: 모듈을 생성하고, 그 안에 표현식 생성 - 단항, 바이너리, 다른 표현식의 블록, 제어 흐름 등 그런 다음 표현식을 본문으로 사용하여 함수를 만듭니다. 나처럼 낮은 수준의 전환 그래프가 있는 경우 relooper 구성 요소가 도움이 될 것입니다. 내가 아는 한, 블록 경계를 벗어나지 않는 한 블록 내 실행 흐름에 대한 높은 수준의 제어를 사용하는 것이 가능합니다. 즉, 내부 빠른 경로/느린 경로를 만드는 것이 가능합니다. 내장된 TLB 캐시 처리 코드 내에서 경로 분기가 이루어지지만 "외부" 제어 흐름을 방해하지 않습니다. 리루퍼를 해제하면 해당 블록도 해제되고, 모듈을 해제하면 해당 모듈에 할당된 표현식, 함수 등이 사라집니다. 투기장.

그러나 인터프리터 인스턴스를 불필요하게 생성 및 삭제하지 않고 즉시 코드를 해석하려면 이 로직을 C++ 파일에 넣은 다음 거기에서 준비 작업을 우회하여 라이브러리의 전체 C++ API를 직접 관리하는 것이 합리적일 수 있습니다. 포장지를 만들었습니다.

따라서 필요한 코드를 생성하려면

// настроить глобальные параметры (можно поменять потом)
BinaryenSetAPITracing(0);

BinaryenSetOptimizeLevel(3);
BinaryenSetShrinkLevel(2);

// создать модуль
BinaryenModuleRef MODULE = BinaryenModuleCreate();

// описать типы функций (как создаваемых, так и вызываемых)
helper_type  BinaryenAddFunctionType(MODULE, "helper-func", BinaryenTypeInt32(), int32_helper_args, ARRAY_SIZE(int32_helper_args));
// (int23_helper_args приоб^Wсоздаются отдельно)

// сконструировать супер-мега выражение
// ... ну тут уж вы как-нибудь сами :)

// потом создать функцию
BinaryenAddFunction(MODULE, "tb_fun", tb_func_type, func_locals, FUNC_LOCALS_COUNT, expr);
BinaryenAddFunctionExport(MODULE, "tb_fun", "tb_fun");
...
BinaryenSetMemory(MODULE, (1 << 15) - 1, -1, NULL, NULL, NULL, NULL, NULL, 0, 0);
BinaryenAddMemoryImport(MODULE, NULL, "env", "memory", 0);
BinaryenAddTableImport(MODULE, NULL, "env", "tb_funcs");

// запросить валидацию и оптимизацию при желании
assert (BinaryenModuleValidate(MODULE));
BinaryenModuleOptimize(MODULE);

... 잊어버린 것이 있다면 죄송합니다. 이는 단지 규모를 표현하기 위한 것이며 자세한 내용은 문서에 나와 있습니다.

이제 다음과 같이 crack-fex-pex가 시작됩니다.

static char buf[1 << 20];
BinaryenModuleOptimize(MODULE);
BinaryenSetMemory(MODULE, 0, -1, NULL, NULL, NULL, NULL, NULL, 0, 0);
int sz = BinaryenModuleWrite(MODULE, buf, sizeof(buf));
BinaryenModuleDispose(MODULE);
EM_ASM({
  var module = new WebAssembly.Module(new Uint8Array(wasmMemory.buffer, $0, $1));
  var fptr = $2;
  var instance = new WebAssembly.Instance(module, {
      'env': {
          'memory': wasmMemory,
          // ...
      }
  );
  // и вот уже у вас есть instance!
}, buf, sz);

어떻게든 QEMU와 JS의 세계를 연결하고 동시에 컴파일된 함수에 빠르게 액세스하기 위해 배열(런처로 가져올 수 있는 함수 테이블)이 생성되고 생성된 함수가 여기에 배치되었습니다. 인덱스를 빠르게 계산하기 위해 처음에는 XNUMX 단어 번역 블록의 인덱스를 그대로 사용했지만, 이후 이 공식을 사용하여 계산된 인덱스가 XNUMX년의 필드에 간단히 들어맞기 시작했습니다. struct TranslationBlock.

또한, 데모 (현재는 어두운 라이센스를 가지고 있음) Firefox에서만 잘 작동합니다. Chrome 개발자는 왠지 준비가 안 됐어 누군가가 천 개가 넘는 WebAssembly 모듈 인스턴스를 만들고 싶어한다는 사실에 그들은 단순히 각 모듈에 기가바이트의 가상 주소 공간을 할당했습니다.

지금은 여기까지입니다. 아마도 누군가 관심이 있다면 또 다른 기사가 나올 것입니다. 즉, 최소한 남아 있습니다. 그냥 블록 장치를 작동시키세요. 네이티브 모듈이 준비될 때까지 이 모든 작업을 수행할 수 있는 인터프리터가 여전히 있기 때문에 JS 세계의 관례대로 WebAssembly 모듈의 컴파일을 비동기식으로 만드는 것이 합리적일 수도 있습니다.

마지막으로 수수께끼: 32비트 아키텍처에서 바이너리를 컴파일했지만 메모리 작업을 통해 코드가 Binaryen, 스택의 어딘가 또는 2비트 주소 공간의 상위 32GB에 있는 다른 곳에서 올라갑니다. 문제는 Binaryen의 관점에서 볼 때 이것이 너무 큰 결과 주소에 액세스하고 있다는 것입니다. 이 문제를 해결하는 방법은 무엇입니까?

관리자의 방식으로

테스트를 끝내지는 못했지만, 처음 든 생각은 "32비트 리눅스를 설치하면 어떨까?"였습니다. 그러면 주소 공간의 윗부분은 커널이 차지하게 됩니다. 유일한 질문은 1Gb 또는 2Gb 중 얼마나 많은 양을 차지할 것인가입니다.

프로그래머의 방식으로 (실무자용 옵션)

주소 공간 상단에 버블을 불어봅시다. 나 자신도 그것이 왜 작동하는지 이해하지 못합니다. 이미 스택이 있어야 합니다. 하지만 "우리는 실무자입니다. 모든 것이 우리에게 도움이 되지만, 그 이유를 아는 사람은 아무도 없습니다..."

// 2gbubble.c
// Usage: LD_PRELOAD=2gbubble.so <program>

#include <sys/mman.h>
#include <assert.h>

void __attribute__((constructor)) constr(void)
{
  assert(MAP_FAILED != mmap(1u >> 31, (1u >> 31) - (1u >> 20), PROT_NONE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0));
}

... Valgrind와 호환되지 않는 것은 사실이지만, 다행스럽게도 Valgrind 자체는 매우 효과적으로 모든 사람을 밀어냅니다 :)

아마도 누군가 내 코드가 어떻게 작동하는지 더 잘 설명해줄 것입니다.

출처 : habr.com