Rust: emscripten으로 Rust를 작동시키십시오.

#3608도 참조하십시오.

여전히 좋을 것입니다. 어떤 성숙 이정표에도 없습니다.

그래도 좋겠지만 그다지 중요하지 않습니다. 많은 런타임이 녹으로 다시 작성되고 있기 때문에 이것은 더 쉬워야 합니다.

https://github.com/mozilla/rust/issues/7282 도

이제 런타임이 Rust로 작성되었으므로 이 버그에 대한 전망이 어떻게 바뀌나요? emscripten을 통해 실행되는 런타임 없는 Hello World를 얻는 것이 얼마나 어려울까요?

보다

• https://github.com/thestinger/rust-core
• https://gist.github.com/klutzy/7819231

지금 emscripten에 대한 정말 멋진 지원을 추가하는 것은 특별히 어렵지 않습니다. 그것은 이미 Rust-core와 거의 작동합니다. 컴파일러에서 적절한 대상 트리플에 대한 지원을 추가하고 다양한 대상 속성을 올바르게 설정한 다음 현재 js, 스레딩 및 컨텍스트 전환에서 작동하지 않는 런타임의 일부 부분을 차단해야 합니다.

1:1 일정 모드가 좀 더 성숙해지면 웹 작업자를 통해 작업에 대한 지원을 추가할 수도 있지만 현재로서는 다른 메시지 전달 솔루션이 필요합니다. 어떤 병렬 지원이 js/emscripten에 추가되는지에 따라 우리는 의미 체계를 정확하게 전달하는 rust의 메시지를 결국 지원할 수 있을 것입니다.

@brson :

-Z no-landing-pads 덕분에 이제 제대로 작동합니다! 이에 대한 명시적 지원을 표준 라이브러리에 추가하는 것이 가능하지만 대부분은 어쨌든(파일, tcp, udp 등) 작동하지 않으므로 필요하지 않다고 생각합니다. 표준 라이브러리가 독립 지원을 선택하면 작동을 시작하고 JavaScript에 매핑할 수 있는 기능을 기반으로 더 많은 문제를 열 ​​수 있습니다.

괜찮으시다면 지금은 이 부분을 열어두고 싶습니다. 이렇게 하면 표준 라이브러리가 확장 가능하고 여러 플랫폼에서 실행될 수 있도록 하는 좋은 단계가 될 것이라고 생각합니다.

대부분의 작업이 완료되었으며 emscripten별 I/O를 제공하기 위해 libemscripten 가 필요할 것이라는 데 동의하지만 이 작업을 수행하는 과정에서 문제가 충분히 발생할 수 있다고 생각합니다. 공개된 문제(여전히 흥미로운 프로젝트입니다!)

@alexcrichton :

상태 업데이트:

@alexcrichton 표준 라이브러리를 더 이해하기 쉬운 종속성을 가진 작은 라이브러리 묶음으로 리팩토링했습니다. 이제 코어, alloc, rand 및 컬렉션 라이브러리를 웹으로 컴파일하는 것은 거의 간단해야 합니다.

이 문제를 해결하는 방법은 다음과 같습니다.

• asm.js로 크로스 컴파일하기 위해 codegen이 작동하는 방식을 이해하기 위해 Rust 및 LLVM 도구 체인으로 몇 가지 실험을 하십시오.
• emscripten으로 libcore를 수동으로 빌드하고 웹에서 작동하는지 증명하십시오.
• emscripten 특정 대상 트리플을 이해하기 위해 rustc 및 mk/platform.mk를 수정하고 libcore.rlib만 포함하는 크로스 컴파일 도구 체인을 생성합니다.
• liballoc이 시스템(이 경우 emscripten 제공) malloc과 함께 작동하도록 허용한 다음 다른 런타임 프리 크레이트와 함께 작동하도록 하여 liballoc을 처리합니다.

꽤 좋은 시작입니다!

좋아, 그래서 나는 첫 번째 단계로 시도했고 분명히 박쥐에서 바로 문제가 발생했습니다.

libcore 를 --emit bc libcore 로 비트코드로 컴파일했고 emcc -O0 로 컴파일하려고 하면 다음을 얻습니다.

/Users/arcnor/emscripten-fastcomp/build/bin/llvm-nm: /tmp/tmpfTkmfj/core_0.o: Invalid CMPXCHG record.
/Users/arcnor/emscripten-fastcomp/build/bin/opt: /tmp/tmpfTkmfj/core.bc: error: Invalid CMPXCHG record
Traceback (most recent call last):
  File "/Users/arcnor/emscripten/emcc", line 1573, in <module>
    shared.Building.llvm_opt(final, link_opts)
  File "/Users/arcnor/emscripten/tools/shared.py", line 1335, in llvm_opt
    assert os.path.exists(target), 'Failed to run llvm optimizations: ' + output
AssertionError: Failed to run llvm optimizations:

이것에 대해 무엇을 할 수 있는지 확실하지 않습니다. 아니면 rustc --emit 출력을 사용할 수 없기 때문입니다.

여기에 댓글을 달 수 있는 곳이 아니라면 죄송합니다...

또한 더 간단한 libnum 시도했는데 bc 가 올바르게 생성되지만 emcc 프로세스 중에 잘못된 트리플을 사용하고 결과 . js에는 libnum 내부에 기능이 없으므로 여기에서 너무 순진한 것 같습니다. :)

@Arcnor 이전에 emscripten으로 간단한 테스트를 컴파일한 사람들에게 프로세스에 대해 물어볼 수 있습니다. 몇 가지 아이디어만 있습니다.

• LLVM 비트코드는 버전마다 변경되며 Rust가 사용하는 버전은 항상 emscripten과 동일하지 않습니다. 비교적 유사한 버전의 LLVM을 사용하여 둘 다 가져오면 호환성이 향상될 수 있습니다.
• 오류 메시지에서 emscripten의 새로운 'fastcomp' 백엔드를 사용하는 것으로 보입니다. 이것은 이전 백엔드보다 Rusty 워크로드에서 덜 테스트될 수 있습니다. 이전 백엔드를 수동으로 선택하면 최소한 다른 결과가 생성될 수 있습니다.
• Emscripten은 일반적으로 자체 타겟 트리플을 사용하므로, 동일한 타겟 트리플을 사용하려면 rustc를 설득해야 할 수도 있습니다.

libcore 를 컴파일하려고 할 때 발생하는 오류는 이 emscripten 문제와 관련된 것으로 보입니다. libcore 를 llvm 바이트코드로 컴파일하면 llvm 원자 명령어가 생성되지만 emscripten은 원자 명령어를 지원하지 않습니다.

녹슨 쪽에서 이 문제를 해결할 수 있는 방법이 있을 수 있지만 emscripten 문제의 주석을 기반으로 emscripten에서 atomics에 대한 지원을 얻는 것이 가장 합리적이라고 생각합니다.

emscripten에 자체 플랫폼이 있는 경우 단일 스레드 변형에 대한 모든 원자를 cfg-out할 수 있지만 업스트림 emscripten에 이것을 갖는 것이 더 낫다는 데 동의합니다!

내가 틀리지 않았다면 emscripten의 새로운 "fastcomp" 백엔드는 LLVM의 포크이므로(이전 백엔드는 LLVM 위의 계층일 뿐임) fastcomp의 LLVM 버전은 아마도 업그레이드하기 어렵고 업그레이드되지 않을 것입니다 자주.

이것은 Rust의 출력과 호환되어야 하는 경우 문제가 됩니다. 예를 들어 현재 fastcomp의 LLVM 버전은 3.3이고 Rust에서 사용하는 LLVM은 3.4입니다.

오래된 emscripten 백엔드는 더 이상 사용되지 않으며 공식 문서에 따라 사용해서는 안 되므로 사용하는 옵션이 아닐 수 있습니다.

현재로서는 emscripten용으로 컴파일하려고 하는 유일한 사람인 것 같습니다.

기록을 위해 내가 시도한 것은 다음과 같습니다.

• 바이트코드(Rust의 LLVM 3.4에 의해 생성됨)로 컴파일하고 이를 fastcomp(LLVM 3.3의 분기)에 전달 ; fastcomp가 충돌하게 만듭니다.
• IR로 컴파일하고 LLVM 3.3과 호환될 때까지 수동으로 편집하고 fastcomp에 전달합니다. 사소하지 않은 코드에 대해 수정하기에는 너무 복잡하고 너무 많은 것들이 있습니다.
• emscripten의 fastcomp를 가리키는 --llvm-root Rust stage1 컴파일 ; ARM/MIPS/etc에 대한 지원을 제거했기 때문에 작동하지 않았습니다. 그들의 포크에서 (나는 이것 때문에 메이크 파일과 연결 중에 오류가 발생합니다)
• 3.3 시대의 오래된 커밋을 가리키도록 Rust의 소스 코드에서 LLVM git 하위 모듈을 수정합니다. LLVM의 특정 지점에서 segfault가 발생합니다.
• 미리 컴파일된 LLVM 3.3을 가리키는 --llvm-root Rust 컴파일(공식 우분투 저장소에서 가져옴) ; stage1 컴파일이 끝날 때 어설션 가져오기가 실패하고 생성된 rustc 바이너리가 작동하지 않습니다.

누군가 아이디어가 없는 한 제 결론은 emscripten이 업그레이드될 때까지 기다려야 한다는 것입니다.

럼 이 작동하는 것 같습니다. 아마도 이것은 도움이 될 것입니다

사소한 업데이트: emscripten-fastcomp가 LLVM 3.4로 업데이트되었으며 나중에 LLVM 3.5로 업데이트됩니다.

@tomaka 3.4 버전으로

@ibdknox 3.4는 3.5와 호환되지 않습니다.
간단한 hello world조차도 실패한 주장을 생성합니다: LLVM ERROR: 0 && "some i64 thing we can't legalize yet"

흠. rustc --emit ir foo.rust 에서 출력을 가져와 emscripten-incoming을 통해 실행할 수 있었습니다. 녹이 이제 LLVM 3.5에 있습니까?

Rust는 오랫동안 LLVM 3.5를 사용해 왔습니다. 운이 좋고 호환되지 않는 것이 생성되지 않을 수 있습니다.
예를 들어 다음은 잘 컴파일됩니다.

#[start]
fn main(_: int, _: *const *const u8) -> int {}

이것은 호환되지 않는 IR 때문이 아닙니다.

fn main() { println!("hello world"); }

@ibdknox http://www.reddit.com/r/rust_gamedev/comments/2n0x08/emscripten_experiments/
생각보다 불호가 적은 것 같습니다.

업데이트로 현재 3.5로 업데이트된 emscripten으로 hello world를 컴파일하면 다음과 같은 결과가 나타납니다.

Value:   %28 = call fastcc { i8, [0 x i8], [0 x i8] } @_ZN3fmt5write20h2c56fdda0b308d94DFAE({ i8*, void (i8*)** }* noalias nocapture dereferenceable(8) %arg.i, %"struct.core::fmt::Arguments[#3]"* noalias nocapture readonly dereferenceable(24) %__args31), !noalias !22
LLVM ERROR: Unrecognized struct value
Traceback (most recent call last):
  File "/Users/chris/Downloads/emsdk_portable/emscripten/incoming/emcc", line 1259, in <module>
    shared.Building.llvm_opt(final, link_opts)
  File "/Users/chris/Downloads/emsdk_portable/emscripten/incoming/tools/shared.py", line 1401, in llvm_opt
    assert os.path.exists(target), 'Failed to run llvm optimizations: ' + output
AssertionError: Failed to run llvm optimizations:

내가 컴파일하는 방법은 다음과 같습니다.

rustc --target i686-apple-darwin -C lto --emit ir foo.rust
emcc -v foo.ll -o test.html

그러나 fmt를 가져오지 않는 것처럼 보이는 것들이 일반적으로 작동하는 것 같습니다.

나는 이것을 조사하는 지난 주에 나의 자유 시간을 보냈다. 나는 여름과 지금 사이에 언젠가 Rust의 책을 읽었고 언어의 역학을 정말 좋아했지만 최근에서야 그것을 구현하기 시작했습니다. 나는 이번 주에 배운 것에 대해 Rust 컴파일러에 대해 아는 만큼만 알고 있지만 기여할 수 있기를 바랍니다.

그래서 내가 배운 것 중 가장 먼저 주목해야 할 것은(그러나 알아차리기까지 며칠이 걸렸다) Rust가 7월에 LLVM 3.6으로 옮겼다는 것입니다. 따라서 현재 버전의 Rust와 emscripten-fastcomp는 호환되지 않습니다.

emscripten-fastcomp 1.29.2를 가리키는 --llvm-root 녹을 컴파일하려고 시도했는데 다음 오류가 발생했습니다.

rustc: x86_64-apple-darwin/stage2/lib/rustlib/x86_64-apple-darwin/lib/libcore
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: http://doc.rust-lang.org/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'assertion failed: self.raw.hash != self.hashes_end', /Users/zen/Code/rust/src/libstd/collections/hash/table.rs:776


make: *** [x86_64-apple-darwin/stage2/lib/rustlib/x86_64-apple-darwin/lib/stamp.core] Error 101

이 오류에 도달하기 위해 emscripten-fastcomp를 구성하고 구축했습니다.

../configure --enable-optimized --disable-assertions --enable-targets=host,js,arm,aarch64,mips

emscripten의 가이드가 권장하는 대신

../configure --enable-optimized --disable-assertions --enable-targets=host,js

Rust가 모든 대상에 대해 빌드될 필요는 없지만 현재 항상 모든 대상에 대해 컴파일된 CPU 지원으로 LLVM에 연결됩니다. 이것은 나중에 수정될 수 있는 문제에 대한 해결 방법이므로 해당 구성으로 emscripten-fastcomp를 항상 컴파일할 필요가 없을 수도 있습니다.

Rust가 LLVM 3.6으로 이동했다는 것을 알았을 때 나는 LLVM 3.5인 rust-lang/llvm의 마지막 분기를 찾았습니다. https://github.com/rust-lang/llvm/tree/rust-llvm-2014-07-24 나는 emscripten-fastcomp 대신 그것에 대해 컴파일했고 결과가 궁금했습니다. emscripton-fastcomp 최근 LLVM 3.5로의 이동에 대해 컴파일할 때 동일한 오류가 발생했습니다. 나는 이것을 Rust가 현재 LLVM 3.5와 어떤 식으로든 호환되지 않는다는 의미로 받아들이고 그렇지 않으면 실제로 기대하지 않을 것입니다.

이제 LLVM 3.6:wink에 대한 emscripten-fastcomp를 기다리거나 가져와야 합니다.

나는 아카이브된 0.11 사본을 다운로드했고 emcc 이해했지만 링크 문제에 도달한 hello world를 위한 LLVM IR을 생성할 수 있었다는 점을 언급할 가치가 있습니다. 바이트 코드를 이해하지 못하는 것을 보는 것은 꽤 흥미로웠지만 실제로 연결하려면 Rust 코드 기반에서 작업이 필요합니다.

Rust-lang/llvm을 emscripten-fastcomp에 병합하는 방법을 살펴보았습니다. 당시에는 43개의 파일에 대해 117개의 충돌하는 섹션이 있었습니다.

나는 연결 단계에 도달하기 위해 Rust 0.11과 emcc 1.29.2를 얻는 것을 언급했습니다. 구체적인 결과는 다음과 같습니다.

$ emcc -v hello.ll -o hello.js
INFO     root: (Emscripten: Running sanity checks)
WARNING: Linking two modules of different data layouts: '/Users/zen/.emscripten_cache/libc.bc' is 'e-p:32:32-i64:64-v128:32:128-n32-S128' whereas '/tmp/tmpv_yB8E/hello_0.o' is 'e-p:32:32-f64:32:64-f80:128-n8:16:32'
WARNING: Linking two modules of different target triples: /Users/zen/.emscripten_cache/libc.bc' is 'asmjs-unknown-emscripten' whereas '/tmp/tmpv_yB8E/hello_0.o' is 'i686-apple-darwin'
warning: incorrect target triple 'i686-apple-darwin' (did you use emcc/em++ on all source files and not clang directly?)
warning: unresolved symbol: _ZN2io5stdio12println_args20h0caae70b0e2eb347Iol7v0_11_0E
warning: unresolved symbol: _ZN10lang_start20h70f93b7d0a75f99atre7v0_11_0E

emcc/fastcomp는 기호의 점을 밑줄로 바꾸는 반면 Rust는 접두사에 다른 밑줄을 붙일 것으로 예상하지만 이에 대해서는 잘 모르겠습니다. 해결되지 않은 첫 번째 기호는 i686-apple-darwin 빌드의 libstd에 __ZN2io5stdio12println_args20h0caae70b0e2eb347Iol7v0.11.0E 로 나타납니다. emcc가 빌드된 라이브러리에서 이 기호를 찾는 방법을 알게 되더라도 라이브러리에는 기계어 코드가 포함되어 있고 emcc에는 LLVM 바이트 코드가 필요합니다. 누군가 emscripten용 표준 라이브러리를 컴파일해야 한다고 언급한 것을 기억합니다. 이것은 그 필요성의 일부일 것입니다.

그래서 누군가가 그들 자신을 쏘고 싶어한다면 내가 시도하고 노력할 다음 단계가 있습니다. (또는 내가 얼마나 옳고 그른지 알려줄 수 있습니다.)

• Rust-lang/llvm을 emscripten-fastcomp에 병합
• JS 백엔드 지원 없이 병합된 fastcomp로 러스트 빌드
  이것이 병합을 위한 좋은 온전성 테스트가 되기를 바랍니다.
• emscripten의 트리플을 Rust에 추가하고 빌드하세요.
  내가 말할 수있는 것은 변경하거나 추가해야 할 파일이 많이 있습니다.
  
  
  
  • mk/cfg/asmjs-unknown-emscripten.mk
  
  
  • rt/arch/asmjs/{morestack.S,record_sp.S}(비어 있을 수 있습니까?)
    
    이 파일은 Rust가 LLVM의 분할 스택을 지원하도록 morestack.a를 빌드하는 데 필요합니다. 내가 올바르게 기억한다면 Emscripten의 스택도 헤드입니다. 힙의 반대쪽 끝을 스택으로 사용하고 asmjs의 경우 어레이의 크기를 변경할 수 없으므로 새 스택 세그먼트를 생성하는 것이 불가능합니다. 나는 이것을 비활성화할 수 있는 librustc_back 대상 파일의 TargetOption 필드를 보았습니다.
  
  
  • librustc_trans/trans/cabi_asmjs.rs
  
  
  • librustc_trans/trans/cabi.rs
    
    이것이 필요한지 확실하지 않습니다. 현재로서는 추측일 뿐입니다.
  
  
  • librustc_back/target/asmjs_unknown_emscripten.rs
  
  
  • librustc_back/asmjs.rs
  
  
  • librustc_syntax/abi.rs
  
  
  • librustc_back/back/write.js configure_llvm()
  
  
  • librustc_llvm/lib.rs static_link_hack_this_sucks()
  
  
• 누락된 시스템 인터페이스 구현
  11월에 libgreen이 제거된 것을 보았습니다. emscripten은 브라우저에서 작업자와 공유할 수 있는 어떤 방법을 기다려야 하기 때문에 그런 일이 발생하면 libgreen과 같은 것이 복원되거나 pthread 또는 Windows 스레드 API에 대해 Rust가 빌드되는 방식과 같이 emscripten에 대해 특정한 방식으로 pthread shim되어야 합니다.

아이오도. 아마 제가 모르는 다른 부분들이 있을 겁니다.

"rust-lang/llvm을 emscripten-fastcomp에 병합"

이렇게 하고 싶지 않을 수도 있습니다. Emscripten은 pnacl-llvm/pnacl-clang을 기반으로 하므로 패치에 패치가 있는 포크를 만들고 있는데, 이는 아마도 고통스러울 것입니다. 관심이 있으시면 https://github.com/kripken/emscripten-fastcomp/issues/51#issuecomment -62323164에서 r33 -> r34에서 Emscripten 병합에 대해 수행한 조사에서 분기에 대한 세부 정보를 볼 수 있습니다. .

pnacl이 업스트림을 이전보다 조금 더 가깝게 추적할 계획이라고 들었지만 pnacl 이슈 트래커에서 3.6으로 업데이트하기 위한 관련 문제를 볼 수 없으므로 시간이 걸릴 수 있습니다(특히 3.6은 5일 전에만 분기됨!). ..당신이 문제를 만들 수 있다고 생각합니까? 자신의 Emscripten 포크를 사용하지 않기로 결정했다면 pnacl을 기다리거나 Emscripten이 pnacl에서 업스트림으로 이동하도록 돕는 두 가지 옵션이 표시됩니다.

수정: '지금'을 '아니요'로 수정했습니다. 결정적인 차이.

1.0을 준비하기 위해 대대적인 분류 노력을 기울이고 있습니다. 이것의 일부로, RFC 저장소로 위시리스트와 같은 항목을 옮기고 있습니다. 그곳에서 주요 새 항목에 대해 논의/우선순위를 지정해야 하기 때문입니다.

이 문제는 RFC 저장소로 이동되었습니다: rust-lang/rfcs#604