몇 년 전 Fabrice Bellard jslinux가 작성함 JavaScript로 작성된 PC 에뮬레이터입니다. 그 이후에는 최소한 더 많은 일이 있었습니다. 가상 x86. 그러나 내가 아는 한 그들 모두는 통역사 였고 동일한 Fabrice Bellard와 아마도 자존심이 강한 현대 에뮬레이터가 훨씬 일찍 작성한 Qemu는 게스트 코드의 JIT 컴파일을 호스트 시스템 코드로 사용합니다. 브라우저가 해결하는 작업과 관련하여 반대 작업을 구현해야 할 때인 것 같았습니다. 즉, 기계어 코드를 JavaScript로 JIT 컴파일하는 것인데, 이 경우 Qemu를 포팅하는 것이 가장 논리적으로 보였습니다. 왜 Qemu에는 더 간단하고 사용자 친화적인 에뮬레이터(예를 들어 동일한 VirtualBox)가 설치되어 작동하는 것 같습니다. 하지만 Qemu에는 몇 가지 흥미로운 기능이 있습니다.

• 오픈 소스
• 커널 드라이버 없이 작업하는 능력
• 통역사 모드에서 작업하는 능력
• 다수의 호스트 및 게스트 아키텍처 지원

세 번째 요점과 관련하여 이제 실제로 TCI 모드에서는 게스트 기계 명령어 자체가 해석되는 것이 아니라 여기에서 얻은 바이트코드가 해석되지만 이것이 빌드하고 실행하기 위해 본질을 바꾸지는 않는다는 점을 설명할 수 있습니다. 새로운 아키텍처의 Qemu, 운이 좋다면 C 컴파일러로 충분합니다. 코드 생성기 작성을 연기할 수 있습니다.

그리고 이제 XNUMX년 동안 여가 시간에 Qemu 소스 코드를 여유롭게 만지작거린 끝에 Kolibri OS와 같이 이미 실행할 수 있는 작업 프로토타입이 나타났습니다.

엠스크립트란 무엇인가요?

요즘에는 많은 컴파일러가 등장했으며 그 최종 결과는 JavaScript입니다. Type Script와 같은 일부는 원래 웹용으로 작성하는 가장 좋은 방법으로 고안되었습니다. 동시에 Emscripten은 기존 C 또는 C++ 코드를 가져와 브라우저에서 읽을 수 있는 형식으로 컴파일하는 방법입니다. ~에 이 페이지 우리는 잘 알려진 프로그램의 많은 포트를 수집했습니다: 여기에예를 들어 PyPy를 보면 이미 JIT가 있다고 주장합니다. 사실, 모든 프로그램이 브라우저에서 간단하게 컴파일되고 실행될 수 있는 것은 아닙니다. 특징, 그러나 같은 페이지에 "Emscripten은 거의 모든 것을 컴파일하는 데 사용할 수 있습니다"라는 문구가 있으므로 참아야 합니다. 휴대용 C/C++ 코드를 JavaScript로 변환합니다. 즉, 표준에 따라 정의되지 않은 동작이지만 일반적으로 x86에서 작동하는 여러 작업이 있습니다. 예를 들어 일부 아키텍처에서는 일반적으로 금지되는 변수에 대한 정렬되지 않은 액세스가 있습니다. 일반적으로 , Qemu는 크로스 플랫폼 프로그램이고, 저는 이것이 정의되지 않은 동작을 많이 포함하고 있지 않다고 믿고 싶었습니다. 이를 받아 컴파일한 다음 JIT를 약간 수정하면 끝입니다! 사례...

먼저 시도해보십시오.

일반적으로 Qemu를 JavaScript로 포팅한다는 아이디어를 처음으로 생각해낸 사람은 제가 아닙니다. Emscripten을 사용하여 이것이 가능한지 ReactOS 포럼에 질문이 있었습니다. 이전에도 Fabrice Bellard가 이 작업을 직접 수행했다는 소문이 있었지만 우리는 jslinux에 대해 이야기하고 있었습니다. 제가 아는 한 JS에서 수동으로 충분한 성능을 얻으려는 시도일 뿐이며 처음부터 작성되었습니다. 나중에 Virtual x86이 작성되었습니다. 이에 대한 난독화되지 않은 소스가 게시되었으며, 언급한 대로 에뮬레이션의 더 큰 "현실성"으로 인해 SeaBIOS를 펌웨어로 사용할 수 있게 되었습니다. 또한 Emscripten을 사용하여 Qemu를 포팅하려는 시도가 적어도 한 번 있었습니다. 소켓 페어, 그러나 내가 아는 한 개발은 중단되었습니다.

따라서 여기에 소스가 있고 여기에 Emscripten이 있는 것 같습니다. 가져와서 컴파일하세요. 그러나 Qemu가 의존하는 라이브러리와 해당 라이브러리가 의존하는 라이브러리 등도 있으며 그 중 하나는 다음과 같습니다. 라이브러리, 어떤 glib이 의존하는지. Emscripten용 라이브러리 포트의 대규모 컬렉션에 하나가 있다는 소문이 인터넷에 있었지만 어쩐지 믿기 어려웠습니다. 첫째, 새로운 컴파일러가 될 의도가 없었고 둘째, 너무 낮은 수준의 컴파일러였습니다. 라이브러리를 선택하여 JS로 컴파일하세요. 그리고 이것은 단지 어셈블리 삽입의 문제가 아닙니다. 아마도 비틀면 일부 호출 규칙의 경우 스택에서 필요한 인수를 생성하고 인수 없이 함수를 호출할 수 있습니다. 그러나 Emscripten은 까다로운 작업입니다. 생성된 코드를 브라우저 JS 엔진 최적화 프로그램에 친숙하게 보이도록 하기 위해 몇 가지 트릭이 사용됩니다. 특히, 일부 추상 전환 명령과 함께 수신된 LLVM IR을 사용하는 코드 생성기인 재루핑(relooping)은 그럴듯한 ifs, 루프 등을 다시 생성하려고 시도합니다. 그렇다면 인수는 어떻게 함수에 전달되나요? 당연히 JS 함수에 대한 인수로, 즉 가능하다면 스택을 통하지 않습니다.

처음에는 단순히 JS로 libffi의 대체 코드를 작성하고 표준 테스트를 실행하는 아이디어가 있었지만 결국 기존 코드와 작동하도록 헤더 파일을 만드는 방법에 대해 혼란스러워졌습니다. "과제가 너무 복잡한가요? "우리가 그렇게 멍청한가요?" 말하자면 libffi를 다른 아키텍처로 포팅해야 했습니다. 다행스럽게도 Emscripten에는 인라인 어셈블리용 매크로(Javascript에서는 그렇습니다. 아키텍처가 무엇이든 어셈블러)와 생성된 코드를 즉시 실행하는 기능이 모두 있습니다. 일반적으로 플랫폼 종속 libffi 조각을 한동안 만지작거린 후 컴파일 가능한 코드를 얻었고 처음 접한 테스트에서 이를 실행했습니다. 놀랍게도 테스트는 성공적이었습니다. 내 천재성에 놀랐습니다. 농담이 아닙니다. 첫 번째 출시부터 작동했습니다. 나는 여전히 내 눈을 믿지 않고 결과 코드를 다시 살펴보고 다음에 발굴할 위치를 평가했습니다. 여기서 나는 두 번째로 미쳐버렸습니다. 내 기능이 한 유일한 일은 ffi_call - 성공적인 통화가 보고되었습니다. 전화 자체가 없었습니다. 그래서 저는 올림피아드 학생이라면 누구나 알 수 있는 테스트 오류를 ​​수정한 첫 번째 풀 리퀘스트를 보냈습니다. 실수는 다음과 같이 비교해서는 안 됩니다. a == b 그리고 심지어 어떻게 a - b < EPS - 모듈도 기억해야 합니다. 그렇지 않으면 0은 1/3과 거의 같습니다... 일반적으로 나는 가장 간단한 테스트를 통과하고 glib가 사용되는 특정 libffi 포트로 끝났습니다. 컴파일됨 - 필요하다고 판단하여 나중에 추가하겠습니다. 앞으로는 컴파일러가 최종 코드에 libffi 함수도 포함하지 않은 것으로 나타났습니다.

그러나 이미 말했듯이 몇 가지 제한 사항이 있으며 정의되지 않은 다양한 동작을 자유롭게 사용하는 것 중에서 더 불쾌한 기능이 숨겨져 있습니다. JavaScript는 설계상 공유 메모리를 사용한 멀티스레딩을 지원하지 않습니다. 원칙적으로 이는 일반적으로 좋은 아이디어라고 할 수 있지만 아키텍처가 C 스레드에 연결된 코드를 이식하는 경우에는 그렇지 않습니다. 일반적으로 Firefox는 공유 작업자 지원을 실험하고 있으며 Emscripten에는 이를 위한 pthread 구현이 있지만 저는 그것에 의존하고 싶지 않았습니다. Qemu 코드에서 멀티스레딩을 천천히 근절해야 했습니다. 즉, 스레드가 어디에서 실행되고 있는지 알아내고, 이 스레드에서 실행되는 루프의 본문을 별도의 함수로 이동하고, 이러한 함수를 메인 루프에서 하나씩 호출해야 했습니다.

두 번째 시도

어느 시점에서 문제는 여전히 존재하며, 코드 주위에 목발을 아무렇게나 밀어 넣는 것은 아무 소용이 없다는 것이 분명해졌습니다. 결론: 목발을 추가하는 과정을 어떻게든 체계화해야 합니다. 따라서 당시 최신 버전이었던 2.4.1 버전을 가져왔습니다(2.5.0이 아닙니다. 왜냐하면 새 버전에는 아직 발견되지 않은 버그가 있을 것이기 때문입니다. 버그) 그리고 가장 먼저 한 일은 안전하게 다시 작성하는 것이었습니다. thread-posix.c. 즉, 안전합니다. 누군가가 차단으로 이어지는 작업을 수행하려고 하면 해당 함수가 즉시 호출됩니다. abort() -물론 이것이 모든 문제를 한꺼번에 해결한 것은 아니지만, 적어도 일관성 없는 데이터를 조용히 받는 것보다는 왠지 더 즐거웠습니다.

일반적으로 Emscripten 옵션은 코드를 JS로 포팅하는 데 매우 유용합니다. -s ASSERTIONS=1 -s SAFE_HEAP=1 - 정렬되지 않은 주소에 대한 호출과 같은 일부 유형의 정의되지 않은 동작을 포착합니다(이는 다음과 같은 형식화된 배열에 대한 코드와 전혀 일치하지 않습니다). HEAP32[addr >> 2] = 1) 또는 잘못된 개수의 인수를 사용하여 함수를 호출하는 경우입니다.

그런데 정렬 오류는 별도의 문제입니다. 이미 말했듯이 Qemu에는 코드 생성 TCI(작은 코드 해석기)를 위한 "퇴화된" 해석 백엔드가 있으며, 새로운 아키텍처에서 Qemu를 빌드하고 실행하려면 운이 좋다면 C 컴파일러로도 충분합니다. "운이 좋다면". 나는 운이 좋지 않았고 TCI가 바이트코드를 구문 분석할 때 정렬되지 않은 액세스를 사용한다는 것이 밝혀졌습니다. 즉, 모든 종류의 ARM 및 반드시 레벨화된 액세스가 필요한 기타 아키텍처에서 Qemu는 네이티브 코드를 생성하는 일반적인 TCG 백엔드가 있기 때문에 컴파일하지만 TCI가 작동할지 여부는 또 다른 질문입니다. 그러나 알고 보니 TCI 문서에도 비슷한 내용이 분명히 나와 있었습니다. 결과적으로 Qemu의 다른 부분에서 발견된 정렬되지 않은 읽기에 대한 함수 호출이 코드에 추가되었습니다.

힙 파괴

결과적으로 TCI에 대한 정렬되지 않은 액세스가 수정되었고 프로세서, RCU 및 기타 작은 것들이라고 불리는 메인 루프가 생성되었습니다. 그래서 옵션을 사용하여 Qemu를 시작합니다. -d exec,in_asm,out_asm, 즉 어떤 코드 블록이 실행되고 있는지 말해야 하고, 방송 시 게스트 코드가 무엇인지, 호스트 코드가 무엇인지(이 경우 바이트코드) 작성해야 함을 의미합니다. 시작되고, 여러 변환 블록을 실행하고, RCU가 이제 시작될 것이라는 디버깅 메시지를 쓰고... 충돌이 발생합니다. abort() 함수 내부 free(). 기능을 조작하여 free() 우리는 할당된 메모리 앞의 XNUMX바이트에 있는 힙 블록의 헤더에서 블록 크기나 이와 유사한 것 대신에 가비지가 있다는 것을 알아냈습니다.

힙 파괴 - 정말 귀엽네요... 이런 경우 유용한 해결 방법이 있습니다. (가능하다면) 동일한 소스에서 네이티브 바이너리를 모아서 Valgrind에서 실행하는 것입니다. 얼마 후 바이너리가 준비되었습니다. 동일한 옵션으로 실행합니다. 실제로 실행에 도달하기 전에 초기화 중에도 충돌이 발생합니다. 물론 불쾌합니다. 분명히 소스가 정확히 동일하지 않았으며 이는 놀라운 일이 아닙니다. 왜냐하면 구성이 약간 다른 옵션을 스카우트했지만 Valgrind가 있기 때문입니다. 먼저 이 버그를 수정한 다음 운이 좋다면 , 원본이 나타납니다. 저는 Valgrind에서 같은 것을 실행하고 있습니다... Y-y-y, y-y-y, uh-uh, 시작되었고 정상적으로 초기화를 거쳐 오류는 말할 것도 없고 잘못된 메모리 액세스에 대한 단일 경고도 없이 원래 버그를 지나갔습니다. 그들이 말했듯이 인생은 이에 대비하지 못했습니다. Walgrind에서 시작하면 충돌하는 프로그램이 충돌을 멈춥니다. 그것이 무엇이었는지는 미스터리입니다. 내 가설은 초기화 중 충돌이 발생한 후 현재 명령 근처에서 gdb가 작업을 표시했다는 것입니다. memset-a 중 하나를 사용하여 유효한 포인터가 있음 mmx, 여부 xmm 레지스터를 사용했다면 일종의 정렬 오류였을 수도 있지만 여전히 믿기 어렵습니다.

좋습니다. Valgrind는 여기서는 도움이 되지 않는 것 같습니다. 그리고 여기에서 가장 역겨운 일이 시작되었습니다. 모든 것이 시작된 것처럼 보이지만 수백만 명령 전에 발생할 수 있는 이벤트로 인해 전혀 알 수 없는 이유로 충돌이 발생합니다. 오랫동안 어떻게 접근해야 할지조차 명확하지 않았습니다. 결국 나는 여전히 앉아서 디버깅을 해야 했습니다. 헤더가 다시 작성된 내용을 인쇄하면 숫자가 아니라 일종의 이진 데이터처럼 보이는 것으로 나타났습니다. 그리고 보라, 이 바이너리 문자열은 BIOS 파일에서 발견되었습니다. 즉, 이제 그것이 버퍼 오버플로라고 합리적인 확신을 가지고 말할 수 있었고 그것이 이 버퍼에 기록되었다는 것이 분명해졌습니다. 그렇다면 다음과 같은 것입니다. Emscripten에는 다행스럽게도 주소 공간이 무작위로 지정되지 않고 구멍도 없으므로 마지막 실행에서 포인터로 데이터를 출력하기 위해 코드 중간 어딘가에 쓸 수 있습니다. 데이터를 보고, 포인터를 보고, 변경되지 않았다면 생각할 거리를 얻으세요. 사실, 변경 후 연결하는 데 몇 분 정도 걸립니다. 하지만 무엇을 할 수 있습니까? 결과적으로 BIOS를 임시 버퍼에서 게스트 메모리로 복사하는 특정 라인이 발견되었으며 실제로 버퍼 공간이 충분하지 않았습니다. 이상한 버퍼 주소의 소스를 찾으면 함수가 생성됩니다. qemu_anon_ram_alloc 파일에 oslib-posix.c - 거기에 있는 논리는 다음과 같습니다. 때로는 크기가 2MB인 거대한 페이지에 주소를 정렬하는 것이 유용할 수 있습니다. 이에 대해 우리는 물어볼 것입니다. mmap 먼저 조금 더 그런 다음 도움을 받아 초과분을 반환하겠습니다. munmap. 이러한 정렬이 필요하지 않은 경우 2MB 대신 결과를 표시합니다. getpagesize() - mmap 여전히 정렬된 주소를 제공합니다... 따라서 Emscripten에서는 mmap 그냥 전화해 malloc, 그러나 물론 페이지에 정렬되지 않습니다. 일반적으로 몇 달간 저를 답답하게 했던 버그가 다음과 같은 변경으로 수정되었습니다. двух 윤곽.

호출 기능의 특징

이제 프로세서가 무언가를 계산하고 있으며 Qemu는 충돌하지 않지만 화면은 켜지지 않으며 출력으로 판단하면 프로세서가 빠르게 루프에 들어갑니다. -d exec,in_asm,out_asm. 타이머 인터럽트(또는 일반적으로 모든 인터럽트)가 도착하지 않는다는 가설이 나타났습니다. 실제로 어떤 이유로든 작동했던 네이티브 어셈블리의 인터럽트를 풀면 비슷한 그림이 나타납니다. 그러나 이것은 전혀 답이 아니었습니다. 위 옵션으로 발행된 추적을 비교하면 실행 궤적이 매우 일찍 분기되는 것으로 나타났습니다. 여기서는 런처를 사용하여 녹음된 내용을 비교해야 합니다. emrun 네이티브 어셈블리의 출력으로 출력을 디버깅하는 것은 완전히 기계적인 프로세스가 아닙니다. 브라우저에서 실행되는 프로그램이 어떻게 연결되는지 정확히 모르겠습니다. emrun, 그러나 출력의 일부 라인이 재배열된 것으로 판명되었으므로 diff의 차이는 아직 궤도가 분기되었다고 가정할 이유가 되지 않습니다. 일반적으로 지침에 따르면 ljmpl 다른 주소로의 전환이 있으며 생성된 바이트코드는 근본적으로 다릅니다. 하나는 도우미 함수를 호출하는 명령을 포함하고 다른 하나는 포함하지 않습니다. 지침을 인터넷 검색하고 이러한 지침을 번역하는 코드를 연구한 후, 먼저 레지스터에서 해당 지침 바로 앞에 있다는 것이 분명해졌습니다. cr0 프로세서를 보호 모드로 전환하는 도우미를 사용하여 녹음이 이루어졌고 두 번째로 js 버전이 보호 모드로 전환되지 않았습니다. 그러나 사실 Emscripten의 또 다른 특징은 명령 구현과 같은 코드를 허용하는 것을 꺼린다는 것입니다. call TCI에서는 모든 함수 포인터가 유형을 생성합니다. long long f(int arg0, .. int arg9) - 함수는 올바른 수의 인수를 사용하여 호출되어야 합니다. 이 규칙을 위반하면 디버깅 설정에 따라 프로그램이 충돌하거나(좋은 결과임) 잘못된 함수를 호출하게 됩니다(디버깅하기에는 안타깝습니다). 세 번째 옵션도 있습니다. 인수를 추가/제거하는 래퍼 생성을 활성화하지만 실제로는 XNUMX개가 조금 넘는 래퍼만 필요함에도 불구하고 전체적으로 이러한 래퍼는 많은 공간을 차지합니다. 이것만으로도 매우 슬프지만 더 심각한 문제가 밝혀졌습니다. 래퍼 함수의 생성된 코드에서 인수가 변환되고 변환되었지만 때로는 생성된 인수가 있는 함수가 호출되지 않았습니다. 내 libffi 구현. 즉, 일부 도우미는 단순히 처형되지 않았습니다.

다행히 Qemu에는 다음과 같은 헤더 파일 형태로 기계가 읽을 수 있는 도우미 목록이 있습니다.

DEF_HELPER_0(lock, void)
DEF_HELPER_0(unlock, void)
DEF_HELPER_3(write_eflags, void, env, tl, i32)

그들은 꽤 재미있게 사용됩니다. 첫째, 매크로는 가장 기괴한 방식으로 재정의됩니다. DEF_HELPER_n을 누른 다음 켜집니다. helper.h. 매크로가 구조 이니셜라이저와 쉼표로 확장된 다음 배열이 정의되고 요소 대신 - #include <helper.h> 그 결과, 드디어 직장에서 도서관을 시험해 볼 기회가 생겼습니다. 파이 파싱, 그리고 정확하게 해당 래퍼와 필요한 기능을 생성하는 스크립트가 작성되었습니다.

그래서 그 이후에는 프로세서가 작동하는 것 같았습니다. memtest86+가 네이티브 어셈블리에서 실행될 수 있음에도 불구하고 화면이 초기화되지 않았기 때문인 것 같습니다. 여기서 Qemu 블록 I/O 코드가 코루틴으로 작성되었음을 명확히 할 필요가 있습니다. Emscripten에는 매우 까다로운 구현이 있지만 여전히 Qemu 코드에서 지원되어야 하며 이제 프로세서를 디버그할 수 있습니다. Qemu는 옵션을 지원합니다. -kernel, -initrd, -append, 이를 사용하면 블록 장치를 전혀 사용하지 않고 Linux 또는 예를 들어 memtest86+를 부팅할 수 있습니다. 하지만 여기에 문제가 있습니다. 네이티브 어셈블리에서는 옵션을 사용하여 콘솔에 대한 Linux 커널 출력을 볼 수 있습니다. -nographic, 브라우저에서 실행된 터미널로의 출력은 없습니다. emrun, 안 왔어. 즉, 명확하지 않습니다. 프로세서가 작동하지 않거나 그래픽 출력이 작동하지 않습니다. 그리고 조금 기다리라는 생각이 들었습니다. "프로세서가 잠자기 상태가 아니라 단순히 천천히 깜박이는 것"이라는 것이 밝혀졌고 약 2분 후에 커널은 콘솔에 많은 메시지를 표시하고 계속 정지되었습니다. 일반적으로 프로세서가 작동한다는 것이 분명해졌으며 SDL0를 사용하려면 코드를 자세히 조사해야 합니다. 안타깝게도 저는 이 라이브러리를 어떻게 사용하는지 모르기 때문에 어떤 곳에서는 무작위로 행동해야 했습니다. 어느 시점에서 파란색 배경 화면에 평행 XNUMX 선이 깜박이면서 몇 가지 생각을 암시했습니다. 결국 문제는 Qemu가 하나의 물리적 창에서 여러 개의 가상 창을 열며 Ctrl-Alt-n을 사용하여 전환할 수 있다는 것이 밝혀졌습니다. 네이티브 빌드에서는 작동하지만 Emscripten에서는 작동하지 않습니다. 옵션을 이용하여 불필요한 창을 제거한 후 -monitor none -parallel none -serial none 각 프레임에서 전체 화면을 강제로 다시 그리라는 지시가 갑자기 작동했습니다.

코루틴

따라서 브라우저에서의 에뮬레이션은 작동하지만 블록 I/O가 없기 때문에 흥미로운 단일 플로피를 실행할 수 없습니다. 코루틴에 대한 지원을 구현해야 합니다. Qemu에는 이미 여러 개의 코루틴 백엔드가 있지만 JavaScript와 Emscripten 코드 생성기의 특성으로 인해 스택 저글링을 시작할 수는 없습니다. "모든 것이 사라지고 석고가 제거되는" 것처럼 보이지만 Emscripten 개발자는 이미 모든 것을 처리했습니다. 이것은 꽤 재미있게 구현되었습니다. 의심스러운 함수 호출을 호출해 보겠습니다. emscripten_sleep Asyncify 메커니즘을 사용하는 여러 가지 사례와 포인터 호출 및 이전 두 사례 중 하나가 스택 아래에서 발생할 수 있는 함수에 대한 호출을 포함합니다. 이제 의심스러운 호출이 발생하기 전에 비동기 컨텍스트를 선택하고, 호출 직후 비동기 호출이 발생했는지 확인하고, 발생한 경우 모든 로컬 변수를 이 비동기 컨텍스트에 저장하여 어떤 함수를 표시하는지 나타냅니다. 실행을 계속해야 할 때 제어권을 넘기고 현재 기능을 종료합니다. 효과를 연구할 수 있는 여지가 있는 곳입니다. 망고 — 비동기 호출에서 반환된 후 코드 실행을 계속해야 하는 경우 컴파일러는 의심스러운 호출 이후에 시작하는 함수의 "스텁"을 생성합니다. — 다음과 같이: n 개의 의심스러운 호출이 있는 경우 함수는 n/2 어딘가에서 확장됩니다. times — 그렇지 않은 경우 잠재적으로 비동기 호출을 할 때마다 일부 지역 변수 저장을 원래 함수에 추가해야 한다는 점을 명심하세요. 그 후, 저는 Python으로 간단한 스크립트를 작성해야 했습니다. 이는 "비동기가 스스로 통과하는 것을 허용하지 않는" 것으로 추정되는 특히 과도하게 사용되는 특정 함수 세트를 기반으로 합니다(즉, 스택 승격 및 방금 설명한 모든 것은 그렇지 않습니다). 작업)은 이러한 함수가 비동기로 간주되지 않도록 컴파일러에서 함수를 무시해야 하는 포인터를 통한 호출을 나타냅니다. 그리고 60MB 미만의 JS 파일은 분명히 너무 많습니다. 최소 30개라고 가정하겠습니다. 일단 어셈블리 스크립트를 설정하고 실수로 링커 옵션을 버렸는데 그중에는 -O3. 생성된 코드를 실행하면 Chromium이 메모리를 소모하고 충돌이 발생합니다. 그러다 우연히 그가 다운로드하려고 하는 것을 보았는데... 글쎄요, 제가 500MB가 넘는 Javascript를 신중하게 연구하고 최적화하라는 요청을 받았다면 저도 얼어붙었을 것입니다.

불행하게도 Asyncify 지원 라이브러리 코드의 검사는 완전히 친숙하지 않았습니다. longjmp-s는 가상 프로세서 코드에 사용되지만 이러한 검사를 비활성화하고 모든 것이 괜찮은 것처럼 컨텍스트를 강제로 복원하는 작은 패치 후에 코드가 작동했습니다. 그런 다음 이상한 일이 시작되었습니다. 때때로 동기화 코드 검사가 트리거되었습니다. 실행 논리에 따라 코드를 차단해야 하는 경우 코드를 충돌시키는 것과 동일한 검사가 누군가 이미 캡처된 뮤텍스를 잡으려고 시도했습니다. 다행스럽게도 이것은 직렬화된 코드에서 논리적인 문제가 아닌 것으로 밝혀졌습니다. 저는 단순히 Emscripten에서 제공하는 표준 메인 루프 기능을 사용하고 있었지만 때로는 비동기 호출이 스택을 완전히 풀고 그 순간 실패하기도 했습니다. setTimeout 메인 루프에서 - 따라서 코드는 이전 반복을 떠나지 않고 메인 루프 반복에 들어갔습니다. 무한 루프에서 다시 작성했으며 emscripten_sleep, 뮤텍스 문제가 중지되었습니다. 코드는 훨씬 더 논리적이 되었습니다. 사실 다음 애니메이션 프레임을 준비하는 코드가 없습니다. 프로세서는 단지 무언가를 계산하고 화면은 주기적으로 업데이트됩니다. 그러나 문제는 여기서 끝나지 않았습니다. 때로는 Qemu 실행이 예외나 오류 없이 자동으로 종료되는 경우도 있었습니다. 그 순간 포기했지만 앞으로 문제는 이것이었다고 말할 것입니다. 코 루틴 코드는 실제로 사용하지 않습니다 setTimeout (또는 적어도 생각만큼 자주는 아님): 기능 emscripten_yield 단순히 비동기 호출 플래그를 설정합니다. 요점은 emscripten_coroutine_next 비동기 함수가 아닙니다. 내부적으로 플래그를 확인하고 재설정한 다음 필요한 곳으로 제어를 전송합니다. 즉, 스택 승격이 거기서 끝납니다. 문제는 기존 코루틴 백엔드에서 중요한 코드 라인을 복사하지 않아 코루틴 풀이 비활성화되었을 때 나타나는 use-after-free로 인해 함수가 qemu_in_coroutine 실제로는 false를 반환했어야 하는데 true를 반환했습니다. 이로 인해 전화가 왔습니다 emscripten_yield, 그 위에는 스택에 아무도 없었습니다. emscripten_coroutine_next, 스택이 맨 위로 펼쳐졌지만 setTimeout, 이미 말했듯이 전시되지 않았습니다.

JavaScript 코드 생성

그리고 실제로 여기에는 "다진 고기를 되돌린다"는 약속이 있습니다. 설마. 물론 브라우저에서 Qemu를 실행하고 그 안에서 Node.js를 실행하면 당연히 Qemu에서 코드를 생성한 후 완전히 잘못된 JavaScript를 얻게 됩니다. 그러나 여전히 일종의 역변환입니다.

먼저 Qemu의 작동 방식에 대해 조금 설명합니다. 즉시 양해해 주시기 바랍니다. 저는 전문적인 Qemu 개발자가 아니며 어떤 곳에서는 제 결론이 틀릴 수도 있습니다. “학생의 의견이 반드시 선생님의 의견, 페아노의 공리, 상식과 일치할 필요는 없다”는 말이 있다. Qemu에는 지원되는 특정 수의 게스트 아키텍처가 있으며 각 아키텍처마다 다음과 같은 디렉터리가 있습니다. target-i386. 빌드할 때 여러 게스트 아키텍처에 대한 지원을 지정할 수 있지만 결과는 여러 바이너리일 뿐입니다. 게스트 아키텍처를 지원하는 코드는 차례로 일부 내부 Qemu 작업을 생성하며, TCG(Tiny Code Generator)는 이미 호스트 아키텍처를 위한 기계어 코드로 변환합니다. tcg 디렉토리에 있는 readme 파일에 명시된 대로 이는 원래 일반 C 컴파일러의 일부였으며 나중에 JIT에 맞게 조정되었습니다. 따라서 예를 들어 이 문서의 대상 아키텍처는 더 이상 게스트 아키텍처가 아니라 호스트 아키텍처입니다. 어느 시점에서 특정 호스트 아키텍처에 대한 코드 생성기가 없을 때 코드(거의 동일한 내부 작업)를 실행해야 하는 TCI(Tiny Code Interpreter)라는 또 다른 구성 요소가 나타났습니다. 실제로 문서에 명시되어 있듯이 이 인터프리터는 속도 측면에서 정량적으로뿐만 아니라 질적으로도 항상 JIT 코드 생성기만큼 성능을 ​​발휘하는 것은 아닙니다. 그의 설명이 완전히 관련이 있는지는 확실하지 않습니다.

처음에는 완전한 TCG 백엔드를 만들려고 했지만 소스 코드와 바이트코드 명령에 대한 완전히 명확하지 않은 설명에서 금방 혼란스러워져서 TCI 인터프리터를 래핑하기로 결정했습니다. 이는 다음과 같은 몇 가지 이점을 제공했습니다.

• 코드 생성기를 구현할 때 명령어 설명이 아닌 인터프리터 코드를 볼 수 있습니다.
• 발생한 모든 번역 블록에 대해 함수를 생성할 수는 없지만, 예를 들어 XNUMX번째 실행 후에만 함수를 생성할 수 있습니다.
• 생성된 코드가 변경되면(그리고 이름에 patch라는 단어가 포함된 함수로 판단하면 이것이 가능할 것 같습니다) 생성된 JS 코드를 무효화해야 하지만 적어도 코드를 다시 생성할 수 있는 무언가가 있을 것입니다.

세 번째 사항에 대해서는 코드를 처음 실행한 후에 패치가 가능한지 잘 모르겠지만 처음 두 가지 사항이면 충분합니다.

처음에는 원래 바이트코드 명령어의 주소에 큰 스위치 형태로 코드가 생성되었지만, 이후 Emscripten, 생성된 JS의 최적화 및 재루핑에 대한 기사를 기억하면서 특히 경험적으로는 더 많은 휴먼 코드를 생성하기로 결정했습니다. 번역 블록의 유일한 진입점은 시작점이라는 것이 밝혀졌습니다. 말하자마자 실행된 것은 얼마 후 우리는 ifs를 사용하여 코드를 생성하는 코드 생성기를 갖게 되었습니다(루프는 없었지만). 그러나 불운하게도 충돌이 발생하여 지침의 길이가 잘못되었다는 메시지가 표시되었습니다. 게다가 이 재귀 수준의 마지막 명령은 다음과 같습니다. brcond. 좋아, 재귀 호출 전후에 이 명령어 생성에 동일한 검사를 추가하겠습니다. 그 중 하나도 실행되지 않았지만 어설션 스위치 후에도 여전히 실패했습니다. 결국 생성된 코드를 연구한 후 전환 후 현재 명령어에 대한 포인터가 스택에서 다시 로드되고 생성된 JavaScript 코드가 덮어쓰게 된다는 것을 깨달았습니다. 그래서 그것은 밝혀졌습니다. 버퍼를 XNUMXMB에서 XNUMXMB로 늘려도 아무런 결과가 발생하지 않았으며 코드 생성기가 원형으로 실행되고 있음이 분명해졌습니다. 현재 TB의 경계를 벗어나지 않는지 확인해야 했고, 그렇다면 실행을 계속할 수 있도록 다음 TB의 주소에 빼기 기호를 붙여 발급해야 했습니다. 또한 이는 "이 바이트코드 조각이 변경된 경우 생성된 함수가 무효화되어야 하는가?"라는 문제를 해결합니다. — 이 번역 블록에 해당하는 기능만 무효화하면 됩니다. 그건 그렇고, Chromium에서 모든 것을 디버깅했지만(저는 Firefox를 사용하고 실험을 위해 별도의 브라우저를 사용하는 것이 더 쉽기 때문에) Firefox는 asm.js 표준과의 비호환성을 수정하는 데 도움이 되었습니다. 크롬.

생성된 코드의 예

Compiling 0x15b46d0:
CompiledTB[0x015b46d0] = function(stdlib, ffi, heap) {
"use asm";
var HEAP8 = new stdlib.Int8Array(heap);
var HEAP16 = new stdlib.Int16Array(heap);
var HEAP32 = new stdlib.Int32Array(heap);
var HEAPU8 = new stdlib.Uint8Array(heap);
var HEAPU16 = new stdlib.Uint16Array(heap);
var HEAPU32 = new stdlib.Uint32Array(heap);

var dynCall_iiiiiiiiiii = ffi.dynCall_iiiiiiiiiii;
var getTempRet0 = ffi.getTempRet0;
var badAlignment = ffi.badAlignment;
var _i64Add = ffi._i64Add;
var _i64Subtract = ffi._i64Subtract;
var Math_imul = ffi.Math_imul;
var _mul_unsigned_long_long = ffi._mul_unsigned_long_long;
var execute_if_compiled = ffi.execute_if_compiled;
var getThrew = ffi.getThrew;
var abort = ffi.abort;
var qemu_ld_ub = ffi.qemu_ld_ub;
var qemu_ld_leuw = ffi.qemu_ld_leuw;
var qemu_ld_leul = ffi.qemu_ld_leul;
var qemu_ld_beuw = ffi.qemu_ld_beuw;
var qemu_ld_beul = ffi.qemu_ld_beul;
var qemu_ld_beq = ffi.qemu_ld_beq;
var qemu_ld_leq = ffi.qemu_ld_leq;
var qemu_st_b = ffi.qemu_st_b;
var qemu_st_lew = ffi.qemu_st_lew;
var qemu_st_lel = ffi.qemu_st_lel;
var qemu_st_bew = ffi.qemu_st_bew;
var qemu_st_bel = ffi.qemu_st_bel;
var qemu_st_leq = ffi.qemu_st_leq;
var qemu_st_beq = ffi.qemu_st_beq;

function tb_fun(tb_ptr, env, sp_value, depth) {
  tb_ptr = tb_ptr|0;
  env = env|0;
  sp_value = sp_value|0;
  depth = depth|0;
  var u0 = 0, u1 = 0, u2 = 0, u3 = 0, result = 0;
  var r0 = 0, r1 = 0, r2 = 0, r3 = 0, r4 = 0, r5 = 0, r6 = 0, r7 = 0, r8 = 0, r9 = 0;
  var r10 = 0, r11 = 0, r12 = 0, r13 = 0, r14 = 0, r15 = 0, r16 = 0, r17 = 0, r18 = 0, r19 = 0;
  var r20 = 0, r21 = 0, r22 = 0, r23 = 0, r24 = 0, r25 = 0, r26 = 0, r27 = 0, r28 = 0, r29 = 0;
  var r30 = 0, r31 = 0, r41 = 0, r42 = 0, r43 = 0, r44 = 0;
    r14 = env|0;
    r15 = sp_value|0;
  START: do {
    r0 = HEAPU32[((r14 + (-4))|0) >> 2] | 0;
    r42 = 0;
    result = ((r0|0) != (r42|0))|0;
    HEAPU32[1445307] = r0;
    HEAPU32[1445321] = r14;
    if(result|0) {
    HEAPU32[1445322] = r15;
    return 0x0345bf93|0;
    }
    r0 = HEAPU32[((r14 + (16))|0) >> 2] | 0;
    r42 = 8;
    r0 = ((r0|0) - (r42|0))|0;
    HEAPU32[(r14 + (16)) >> 2] = r0;
    r1 = 8;
    HEAPU32[(r14 + (44)) >> 2] = r1;
    r1 = r0|0;
    HEAPU32[(r14 + (40)) >> 2] = r1;
    r42 = 4;
    r0 = ((r0|0) + (r42|0))|0;
    r2 = HEAPU32[((r14 + (24))|0) >> 2] | 0;
    HEAPU32[1445307] = r0;
    HEAPU32[1445308] = r1;
    HEAPU32[1445309] = r2;
    HEAPU32[1445321] = r14;
    HEAPU32[1445322] = r15;
    qemu_st_lel(env|0, r0|0, r2|0, 34, 22759218);
if(getThrew() | 0) abort();
    r0 = 3241038392;
    HEAPU32[1445307] = r0;
    r0 = qemu_ld_leul(env|0, r0|0, 34, 22759233)|0;
if(getThrew() | 0) abort();
    HEAPU32[(r14 + (24)) >> 2] = r0;
    r1 = HEAPU32[((r14 + (12))|0) >> 2] | 0;
    r2 = HEAPU32[((r14 + (40))|0) >> 2] | 0;
    HEAPU32[1445307] = r0;
    HEAPU32[1445308] = r1;
    HEAPU32[1445309] = r2;
    qemu_st_lel(env|0, r2|0, r1|0, 34, 22759265);
if(getThrew() | 0) abort();
    r0 = HEAPU32[((r14 + (24))|0) >> 2] | 0;
    HEAPU32[(r14 + (40)) >> 2] = r0;
    r1 = 24;
    HEAPU32[(r14 + (52)) >> 2] = r1;
    r42 = 0;
    result = ((r0|0) == (r42|0))|0;
    if(result|0) {
    HEAPU32[1445307] = r0;
    HEAPU32[1445308] = r1;
    }
    HEAPU32[1445307] = r0;
    HEAPU32[1445308] = r1;
    return execute_if_compiled(22759392|0, env|0, sp_value|0, depth|0) | 0;
    return execute_if_compiled(23164080|0, env|0, sp_value|0, depth|0) | 0;
    break;
  } while(1); abort(); return 0|0;
}
return {tb_fun: tb_fun};
}(window, CompilerFFI, Module.buffer)["tb_fun"]

결론

그래서 아직 공사가 완료되지 않은 상태인데, 이 장기 공사를 비밀리에 완벽하게 마무리하는 데 지쳤습니다. 그래서 나는 지금 내가 가지고 있는 것을 출판하기로 결정했습니다. 코드는 실험이고 무엇을 해야 할지 미리 명확하지 않기 때문에 약간 무서운 부분이 있습니다. 아마도 최신 버전의 Qemu 위에 일반적인 원자 커밋을 발행하는 것이 가치가 있을 것입니다. 그동안 Gita에는 블로그 형식의 스레드가 있습니다. 적어도 어느 정도 통과한 각 "레벨"에 대해 러시아어로 된 자세한 설명이 추가되었습니다. 사실 이 글은 결론을 다시 한 번 말한 것입니다. git log.

모두 시도해 볼 수 있습니다. 여기에 (교통에 주의하세요).

이미 작동 중인 것:

• x86 가상 프로세서 실행 중
• 기계 코드에서 JavaScript까지 JIT 코드 생성기의 작업 프로토타입이 있습니다.
• 다른 32비트 게스트 아키텍처를 조합하기 위한 템플릿이 있습니다. 지금 당장 로딩 단계에서 브라우저에서 정지되는 MIPS 아키텍처에 대해 Linux를 감상할 수 있습니다.

너는 어떤 다른 일을 할 수 있니

• 에뮬레이션 속도를 높입니다. JIT 모드에서도 Virtual x86보다 느리게 실행되는 것 같습니다(그러나 에뮬레이트된 하드웨어와 아키텍처가 많은 전체 Qemu가 있을 수 있습니다).
• 일반적인 인터페이스를 만들기 위해 - 솔직히 저는 훌륭한 웹 개발자가 아니기 때문에 지금은 최선을 다해 표준 Emscripten 쉘을 다시 만들었습니다.
• 네트워킹, VM 마이그레이션 등 더 복잡한 Qemu 기능을 시작해 보세요.
• UPD : Qemu 및 기타 프로젝트의 이전 포터들이 했던 것처럼 몇 가지 개발 및 버그 보고서를 Emscripten 업스트림에 제출해야 합니다. 내 작업의 일부로 Emscripten에 대한 그들의 기여를 암시적으로 사용할 수 있게 해준 그들에게 감사드립니다.

출처 : habr.com