# 36120의 PoC도 참조하십시오.

LLD는 현재 링커를 어쨌든 번들로 묶고 있고 MinGW의 링커에는 ASLR 부족에서 bigobj 지원 없음에 이르기까지 다양한 문제가 있기 때문에 LLD는 MinGW 대상에 대한 매우 좋은 후보일 수 있습니다. 네이티브 타겟팅(현재 Rustup의 mingw 패키지는 현재 제한되어 있음)뿐만 아니라 크로스 컴파일할 때 필요한 mingw 라이브러리도 가져올 수 있다면 기본적으로 Linux에서 Rust 크로스 컴파일을 사용할 수 있게 되어 엄청난 개선이 될 것입니다. 사람들이 배포판에서 MinGW를 얻은 다음 배포판이 거의 항상 호환되지 않는 MinGW를 사용하기 때문에 문제가 발생하는 기존 상황보다.

LLD는 몇 가지 이유로 인해 기본적으로 MSVC 대상을 대상으로 하는 좋은 후보가 아닙니다 . 주된 이유는 debuginfo 지원이 부족하기 때문입니다. MSVC 대상으로 크로스 컴파일하려면 재배포할 수 없는 라이브러리가 필요하므로 기본적으로 지원할 수 없습니다.

LLVM 4.0으로 업그레이드하기 위한 추적 문제는 https://github.com/rust-lang/rust/issues/37609 입니다.

레코드 lld는 확실히 Solaris 대상에 대해 준비되지 않았습니다. 그러나 Solaris에서는 기본 ld 대신 lld를 사용해야 한다는 것을 알고 있는 이유가 없습니다. 우리는 이미 Rust가 링크를 위해 gcc를 사용하는 대신 Solaris에서 Solaris ld를 사용하도록 하려면 무엇이 필요한지 살펴보았습니다.

하지 Solaris에서, Solaris 용 빌드 할 때 사용 LLD에 @binarycrusader 이유 중 하나입니다.

PR Rust-lang/rust#40018은 LLD를 링커로 사용할 수 있도록 rustc에 -Z linker-flavor 플래그를 추가합니다. 해당 PR은 Rustc에 LLD를 포함하지 않지만 이를 사용하여 트리 외부 실험을 허용합니다.

@binarycrusader ^ gcc 대신 Solaris의 ld를 직접 사용하는 실험에 도움이 될 수 있습니다.

이제 LLVM 4.0에서 실행 중인 것으로 보입니다. @japaric , 이것은 이제 링커 풍미 플래그를 시스템 링커와 LLD를 비교하고 대조하는 데 쉽게 사용할 수 있음을 의미합니까?

@bstrie #40018이 몇 주 전에 도착했습니다. 그 착륙 이후로 -Z linker-flavor=ld -C linker=ld.lld 를 사용하여 외부 LLD 바이너리를 링커로 사용할 수 있었습니다. gcc와 달리 LLD는 시스템 라이브러리가 어디에 있는지 알지 못하므로 시스템 라이브러리에 링크하는 경우 -C link-args='-L ...' 사용하여 라이브러리 검색 경로를 링커에 전달해야 합니다.

LLVM 4.0이 도움이 되는 것은 LLD를 rustc로 병합하는 것입니다. 이러한 변경으로 MUSL 바이너리 또는 베어메탈 프로그램 연결과 같은 일부 시나리오에서 외부 링커가 필요하지 않습니다. 내가 위에서 언급한 라이브러리 검색 경로 문제에 부딪힐 시스템 라이브러리에 대한 링크가 대부분의 대상에 필요하기 때문에 몇 가지 시나리오를 말하는 것입니다. 이러한 대상의 경우 LLD는 기본적으로 작동하지 않습니다. 그 문제를 해결하는 방법과 위치가 명확하지 않으며 이에 대한 솔루션이 없으면 가장 중요한(계층 1) 대상에 대해 LLD로 전환할 수 없습니다.

@japaric (sysroot 관련 라이브러리) 검색 경로와 -lc -lpthread crt0.o 와 같은 항목을 직접 rustc에 삽입하는 것에 대한 주장은 무엇입니까? 결국 플랫폼에 대한 표준이 없기 때문에 도구 체인의 일부 구성 요소에 포함해야 하며 binutils는 이러한 지식의 좋은 황금 소스가 아닙니다.

내가 생각할 수 있는 유일한 단점은 동일한 트리플이 서로 다른 종류의 시스템에서 서로 다른 검색 경로를 갖는 상황이라는 것입니다(이는 Linux/glibc 트리플에만 해당되며 특히 multilib가 있는 플랫폼에서는 좋지 않음). 이 경우, 나는 clang이 OS 이름을 스누핑하고 OS별 규칙을 하드코딩한다고 생각합니다. 이는 좋지 않은 것처럼 보이지만 Linux에서 실행되는 단일 바이너리를 배포하려는 경우(시스템 링커가 필요하지 않은 경우) 피할 수 없는 것입니다.

@retep998 몇 달 전에 lld를 간략하게 살펴보았습니다. Linux에서 .exe를 크로스 컴파일(크로스 링크?)할 수 없었습니다. lld는 플랫폼 기본 형식만 지원하는 것 같았습니다.

내가 틀렸으면 좋겠어.

LLD의 벤치마크에 따르면 GNU ld보다 성능이 10배 더 우수하고 연결 성능이 현재 컴파일러 속도의 큰 구성 요소이기 때문에 이것을 성능 버그로 태그 지정합니다.

어, 벤치마크를 연결하는 것을 잊었습니다: https://lld.llvm.org/#performance

(LLVM 5.0이 방금 출시된 이후 오늘 관련됨.)

LLD와 연결하는 것이 bfd나 gold보다 훨씬 빠르지만 사용하면 전반적인 성능이 크게 향상될 지는 의문입니다. 그래도 저는 이 문제가 중요하고 우선순위가 되어야 한다고 생각합니다.

@tpimh 실제로 I-slow 태그가 런타임 성능 버그 또는 컴파일 타임 성능 버그를 나타내는지 여부를 완전히 확신할 수 없지만 후자로 의도했습니다. 그리고 내가 시간 경과 출력 연결을 볼 때 IME는 일반적으로 대부분의 것보다 훨씬 긴 상위 3개의 가장 긴 단계에 있으므로 연결 시간을 절반으로 줄이는 것조차 아마도 큰 승리가 될 것입니다(특히 Servo 및 rustc와 같은 큰 경우).

@bstrie I-slow는 나쁜 런타임 성능을 위한

Linux에서 Windows로의 교차 링크라는 모호한 주제에 관심이 있는 모든 사람에게 희소식입니다. 이전에 lld로는 불가능하다고 말했지만 이는 lld의 ld 풍미에만 해당됩니다. lld의 link.exe 맛(lld-link)이 가능합니다.

특히 Rust의 경우 몇 가지 코드 변경으로 오늘 이 작업을 수행할 수 있습니다.

1. mingw-w64 CRT의 아주 작은 부분집합을 .o 개체 파일로 컴파일해야 합니다. 즉, 일부 스레드 로컬 저장소 초기화. chkstk도 필요합니다.

2. lld는 MinGW의 일반적인 가져오기 라이브러리를 좋아하지 않습니다. 대신 lld-link 또는 llvm-dlltool을 사용하여 .def 파일을 .lib 파일로 빌드해야 합니다.

3. IMPORT_NAME_NOPREFIX를 다음과 같이 처리하도록 lld를 수정합니다.
   IMPORT_NAME_UNDECORATE, 2단계를 사용해도 .libs가 완벽하지 않기 때문입니다.

4. Rust의 seh.rs를 수정하여 TYPE_INFO_VTABLE을 ptr::null()로 바꾸세요. ??_7type_info@@6B@ 기호가 MinGW에 정의되어 있지 않기 때문에 필요합니다. 그런 다음 Rust를 빌드하고 설치합니다.

5. .cargo/config를 사용하여 사용자 정의 래퍼 스크립트를 링커로 지정합니다.

6. 래퍼 링커 스크립트는 대부분 전달된 매개변수를 사용하여 lld-link를 호출해야 합니다. 그러나 몇 가지 조정을 해야 합니다.

   a) 파일 이름 대소문자 수정(예: AdvAPI32.Lib을 advapi32.lib로 변경)

   b) Rust가 생성하는 .def 파일을 수정하여 기호에 추가 밑줄을 붙입니다.

   c) 진입점(/entry)을 재정의합니다. 이름 맹글링 문제로 인해 필요합니다.

   d) 1단계에서 컴파일한 mingw-crt 개체 파일을 추가합니다.

7. xargo --target=i686-pc-windows-msvc를 사용하여 Rust 프로젝트를 빌드합니다.

위의 단계를 수행하면 Rust 코드를 교차 컴파일할 수 있습니다. Rust의 SEH 기반 해제를 사용하여 패닉에 빠지고 패닉을 잡을 수도 있습니다.

@iainnicol msvc 대상을 MinGW 비트와 혼합하고 있기 때문에 모든 이상한 수정을 수행해야 합니다. 기존 VC++ 설치에서 라이브러리를 복사하기만 하면 모든 수정이나 MinGW 비트 없이 lld-link를 정상적으로 사용할 수 있습니다.

하지만 기존 VC++ 설치를 사용하고 싶지 않습니다. 정크를 다운로드하고 설치하는 데 8시간을 소비하고 재배포하는 데 훨씬 더 적은 시간을 소비하지 않고 하나를 얻을 수 있는 방법은 없습니다.

독립 실행형 빌드 도구는 이미 언급한 것이 아니라면 훨씬 더 가볍습니다. 이 경우 MinGW가 실제로 MSVC와 호환되도록 개선하거나 다시 만드는 작업을 해야 합니다.

독립 실행형 빌드 도구는 훨씬 더 가볍습니다.

나는 마이크로소프트가 그것들을 배포한다는 것을 깨닫지 못했다. 그들과 연결해 주시겠습니까? 실제로 실행하지 않고 설치 아카이브를 추출하는 합리적인 방법이 있습니까? 즉, msi 또는 이와 유사한 것입니까?

여기에 있습니다: http://landinghub.visualstudio.com/visual-cpp-build-tools

2015 및 2017 버전 모두 exe이지만 다음을 통해 2017 exe가 원하는 것을 제공하도록 설득할 수 있습니다. https://docs.microsoft.com/en-us/visualstudio/install/install-vs- 일관성 없는 품질 네트워크

Windows에서 이 작업을 제대로 수행하려면 먼저 Windows SDK 또는 MinGW의 가져오기 라이브러리가 필요하지 않도록 https://github.com/rust-lang/rust/issues/30027 이 필요합니다. 그러면 우리에게 남은 것은 CRT 비트를 우리의 순수한 Rust 버전(수학/기억 함수, 진입점, Rust가 필요로 하는 몇 가지 다른 런타임 비트)으로 바꾸는 것뿐입니다. Windows 바이너리를 만드십시오! 이것의 단점은 C/C++ 코드를 정적으로 링크할 수 없다는 것입니다. 왜냐하면 이것이 MinGW 또는 VC++에서 적절한 CRT에 링크하는 데 매우 크게 의존하기 때문입니다. 물론 Rust의 요점은 Rust에서 모든 것을 다시 작성하는 것이므로 이것은 그다지 문제가 되지 않습니다.

Linux에서 Windows로의 교차 링크라는 모호한 주제에 관심이 있는 모든 사람에게 희소식입니다. 이전에 lld로는 불가능하다고 말했지만 이는 lld의 ld 풍미에만 해당됩니다. lld의 link.exe 맛(lld-link)이 가능합니다.

이제 ld 맛으로도 가능할 것 같습니다. https://reviews.llvm.org/rL312926

새로운 lld의 MinGW 호환 드라이버는 lld-link 링커에 대한 래퍼입니다. 내부적으로 Unix-ish 옵션을 Windows-ish 옵션으로 변환한 다음 lld-link의 진입점을 호출합니다. 당신이 그것을 사용하기를 원하는지 확신할 수 없습니다. (래퍼 드라이버가 불완전하고 사용할 준비가 되지 않은 것을 제외하고) MinGW용 Makefile이 이미 있지 않는 한 작업을 더 쉽게 만들지 않는 것 같습니다.

크로스 컴파일에 대해 (아마도 어리석은) 질문이 있습니다. Windows에서 dllimport된 모든 기호에는 가져오기의 DLL 이름이 있습니다. MSVC 라이브러리 파일이 없는 경우 dllimport'ed 기호를 가져오는 파일을 어떻게 알 수 있습니까?

크로스 컴파일에 대해 (아마도 어리석은) 질문이 있습니다. Windows에서 dllimport된 모든 기호에는 가져오기의 DLL 이름이 있습니다. MSVC 라이브러리 파일이 없는 경우 dllimport'ed 기호를 가져오는 파일을 어떻게 알 수 있습니까?

가져오기 라이브러리가 없는 경우 가져오기 라이브러리를 만들거나 https://github.com/rust-lang/rust/issues/30027을 구현하여 winapi 가 모든 어려운 작업을 수행할 수 있도록 해야 합니다. 각 기호가 서수와 같은 엉뚱함과 함께 어떤 DLL에서 왔는지 지정하는 작업. 뭔가는 코드에서 가져 오기 라이브러리 나 주석이든, DLL의 심볼 / 서수에 링크시의 심볼 매핑을 지정할 수 있습니다.

https://reviews.llvm.org/rL311734 를 가져온 후 macOS에서 lld를 사용하여 rustc를 부트스트랩할 수 있습니다. 아직 조사해야 하는 dylib 메타데이터에 문제가 있는 것 같습니다.

https://github.com/rust-lang/rust/pull/36120 을 부활시키는 분기가 https://github.com/rust-lang/rust/issues/43370에서 차단됩니다

@tamird : #43370이 폐쇄되었습니다.

LLD가 https://github.com/rust-lang/rust/pull/48125 에 추가되었으며 현재 Tier 1 플랫폼(mac, linux, windows)과 함께 제공됩니다. 기본적으로 대부분의 플랫폼에서 작동하지 않을 수 있지만 각 플랫폼에 대해 -Z linker-flavor 로 테스트할 수 있습니다. 그러나 MSVC에서는 기본적으로 작동합니다. 예를 들어:

$ RUSTFLAGS='-Z linker-flavor=lld-link' cargo build

Cargo의 자체 링크 시간을 2.5초에서 1.5초로 줄였습니다.

@alexcrichton , 다음 단계는 무엇입니까? 이상적으로는 모든 플랫폼에서 기본적으로 LLD가 작동하도록 하고(얼마나 많은 작업이 소요될지에 대한 개념이 없음), 컴파일 시간/런타임 벤치마크를 실행하여 LLD를 기본값으로 설정하는 것이 합리적인지 확인하고 싶습니다. 모든 플랫폼. 특히 증분 컴파일에서는 연결 성능이 그 어느 때보다 중요해질 것입니다.

특히 증분 컴파일에서는 연결 성능이 그 어느 때보다 중요해질 것입니다.

연결 성능이 여전히 지원하는 플랫폼에서 증분 연결을 활성화하는 것과 같은 작업을 수행하기에 충분히 중요하지 않다는 것은 유감입니다. https://github.com/rust-lang/rust/issues/37543

@bstrie 저는 이것이 다른 플랫폼에서 작동하도록 하는 다음 단계라고 생각합니다. :)

그것이 수반하는 것에 관해서는 확실하지 않지만 이미 MSVC에서 작동합니다. MinGW/Linux에서 작동하는 것과는 거리가 멀고 OSX에서는 매우 가깝습니다. 교차 아키텍처 지원에 관해서도 잘 모르겠습니다. 가까운 장래에 wasm 플랫폼 이외의 다른 것에 대해 "안정화"할 것이라고 기대하지 않습니다.

@alexcrichton "안정화"를 지정하는 방법을 여쭤봐도 될까요? 왜 다른 주요 플랫폼 녹 지원에 대해 lld와의 연결을 "안정화"하는 것이 불가능합니까? (예: macOS용 Linux에서 실행 파일을 교차 컴파일).

예를 들어 Linux에서 macOS(x86_64-apple-darwin)용 실행 파일을 교차 컴파일하는 데 필요한 작업은 xcode sdk를 획득하고 전체 도구 체인을 구축하는 것과 같은 간단한 단계가 필요합니다.

@cynecx 좋은 질문입니다! 별로 생각하지 않은 것 중 하나. 그러나 다른 플랫폼에 LLD를 추가했다는 이유만으로 LLD를 사실상 안정화하고 싶지는 않다고 생각합니다. LLD를 올바르게 표시하고 제대로 노출하려면 시간과 노력이 필요할 것입니다.

예를 들어 Linux에서 macOS(x86_64-apple-darwin)용 실행 파일을 교차 컴파일하는 데 필요한 작업에는 xcode sdk를 획득하고 전체 도구 체인을 구축하는 것과 같은 간단한 단계가 필요합니다.

LLD는 여기에서 실제로 도움이 되지 않습니다. 재배포할 수 없는 헤더가 있기 때문에 여전히 Xcode SDK가 필요합니다(그리고 빌드하는 항목에 따라 다른 SDK 도구도 필요합니다).

이제 야간에 내장된 LLD의 정말 좋은 점은 RUSTFLAGS='-Z linker-flavor=ld.lld' cargo build --target x86_64-unknown-linux-musl 를 사용하여 순수한 Rust 프로젝트를 Windows에서 Linux로 쉽게 교차 컴파일할 수 있다는 것입니다. 단순히 Rust를 설치할 수 없는 Linux 머신을 위한 작은 도구를 작성하는 데 좋습니다.

가까운 장래에 wasm 플랫폼 이외의 다른 것에 대해 "안정화"할 것이라고 기대하지 않습니다.

@rkarp가 말했듯이 매우 일반적인 사용 사례는 컨테이너화된 Linux 워크로드를 지원하기 위해 x86_64-unknown-linux-musl(그리고 결국에는 군마)을 대상으로 하는 것입니다. 이 이동은 정말 잘한다는 것을 것들 중 하나이며 우리는 매우 가까운 녹 마찬가지로 수행 할 수있을 것 같다 곳. 실제 사용 측면에서 x86_64-unknown-linux-musl에 대한 LLD가 실제로 wasm보다 훨씬 더 광범위하게 사용될 것입니다.

더 일반적으로, 교차 구축에 관해서는 "모든 호스트 및/또는 모든 대상에서 작동해야 함" 접근 방식이 의미가 없다고 생각합니다. 목표가 작동하기 시작할 때 목표별로 이를 안정화하는 것이 합리적이라고 생각합니다.

특히 x86_64-unknown-linux-musl 타겟에 대한 LLD를 최대한 빨리 안정화하려는 노력에 도움을 드리고 싶습니다.

내 프로젝트에는 37개의 상자가 있고 빌드 링크는 약 70개의 바이너리(많은 테스트)입니다. 비과학적으로 ( top ) 빌드 시간의 적어도 절반은 ld 만 실행하고 있습니다. lld를 사용하면 빌드 속도가 많이 빨라질 것으로 예상합니다. 우리는 안정적인 Rust를 사용 중이고 아직 lld 6.0을 작동시키지 못했습니다.

@briansmith musl과 사용 사례에 대해 LLD를 테스트해 보셨습니까? 이론상으로 테스트하기 위해 해야 할 일은 -Z linker-flavor=ld.lld 를 전달하는 것뿐이며, 이것이 그럴듯해 보인다면 기본값을 전환할 수 있습니다!

@rocallahan 확인을 위해 현재 골드 링커를 사용하고 -Z linker-flavor=ld.lld 작동하고 더 빠르다면 안정화를 모색할 수 있습니다! 어떤 플랫폼에 있었나요?

비과학적으로(눈부신 정상) 빌드 시간의 최소 절반은 ld를 실행하고 있습니다.

디버그 빌드 BTW용입니다.

여러분은 현재 골드 링커를 사용하고 계시죠? (afaik으로서 표준 binutils 링커보다 빠름)

아니요, 표준 GNU 링커인 Fedora 시스템 링커입니다.

어떤 플랫폼에 있었나요?

Fedora 27, SSD가 탑재된 쿼드 코어 Skylake 노트북. 몇 가지 성능 수치를 얻을 것입니다.

아 그렇군요 알아두시면 좋습니다! 디버그 빌드는 링커 개선보다는 분할 드워프(https://github.com/rust-lang/rust/issues/34651)의 링크 시간에서 가장 많은 이점을 얻을 수 있습니다.

그러나 타이밍 정보의 경우 ld.gold 및 ld.lld 마인드 테스트를 할 기회가 있다면 @rocallahan ?

확신하는. 또한 문제 #48762는 Linux 디버그 링크 시간을 단축하기 위한 매우 낮은 결과임을 상기시켜야 합니다. (우리는 이미 실행 파일에서 .debug_pubnames / .debug_pubtypes 을 삭제하는 해킹된 링커 스크립트를 사용하고 있습니다.)

분할 DWARF는 좋을 수 있지만 사용자에게 문제를 일으킬 수도 있습니다. 나는 그 문제에 대해 논평할 것이다.

@briansmith musl과 사용 사례에 대해 LLD를 테스트해 보셨습니까? 이론적으로 테스트하기 위해 수행해야 하는 모든 작업은 -Z linker-flavor=ld.lld를 전달하는 것입니다. 이 작업이 그럴듯해 보인다면 기본값을 전환할 수 있습니다!

알겠습니다. 테스트해 보겠습니다. 아마도 처음에는 "default"와 "only on nightly" 사이에 중간 지점이 있어야 합니다. -Z 에서 할 수 있는 것처럼 LLD를 사용하도록 선택하는 어떤 방법이지만 작동하려면 -Z 를 사용하지 않습니다. 안정적인 빌드에서.

그러나 안정적인 빌드에서 작동하도록 -Z를 사용하지 않습니다.

RUSTC_BOOTSTRAP=1 RUSTFLAGS="-Z linker-flavor=foo" cargo build 시도할 수 있습니다.

부트스트랩 플래그를 추천하지 않으시겠습니까? 충분한 프로젝트가 사물에 의존한다면 전체 안정성 메커니즘의 요점을 무너뜨리면서 사실상 안정적이 될 것이라고 걱정합니다.

죄송합니다 =/

데이터 포인트로, Rust 저장소 자체에서 rustc_trans 크레이트를 연결하는 것은 로컬 컴퓨터에서 78초 링크 시간에서 1초 링크 시간으로 급락했습니다.

내 성능은 크레이트 계층 구조의 맨 아래 근처에 있는 크레이트로 공백을 변경한 결과입니다. 쿼드 코어 Skylake 노트북, 16GB RAM, rustc 1.24.0, LLD 7.0.0, GNU ld 2.29-13. .debug_pubnames 및 .debug_pubtypes 를 버리는 사용자 지정 링커 스크립트를 사용합니다. LLD는 링커 스크립트가 있을 때 매우 다른 코드 경로를 사용하므로 영향을 미칠 수 있습니다.

GNU ID:

real    2m39.138s
user    8m18.992s
sys 1m37.513s

LLD:

real    2m19.164s
user    6m4.477s
sys 0m56.858s

Gold는 작동하지 않았고 링커 스크립트에 방해가 되었습니다. 결과는 상당히 안정적입니다. LLD는 종단 간 시간에 그다지 영향을 미치지 않지만 CPU 사용량을 크게 줄입니다. 그것은 우리의 빌드가 lds가 완료되기를 기다리는 데 많은 시간을 소비하지 않는다는 것을 의미한다고 생각합니다. 그러나 그것들을 실행하는 데 많은 CPU 시간을 소비합니다.

GNU ld에서 lld로 전환하면 일반적인 "사소한 변경 및 재구축" 작업 부하가 2.5배 이상 빠르게 실행되는 실제 예는 #50584를 참조하십시오.

Er https://github.com/rust-lang/rust/issues/50584#issuecomment -400918647이 더 적절합니다.

LLD를 안정화하기 위한 다음 단계는 모든 대상(Windows + Mac + Linux)에서 작동하는 -Z linker-flavor=lld와 같은 플래그를 얻는 것입니다. 다양한 플랫폼에서 작동하기 위해 필요한 모든 작업을 수행합니다.

완료되면 커뮤니티에 광고하여 피드백을 요청할 수 있습니다. 여기에서 타이밍 정보와 LLD에 보낼 버그 보고서를 모두 얻을 수 있습니다. 모든 것이 순조롭게 진행된다면(완전히 새로운 링커에서는 의심스럽긴 하지만, 여러분은 절대 모릅니다!) 기본적으로 이 기능을 켤 수 있습니다. 그렇지 않으면 LLD 선택을 안정화한 다음 Cargo에 옵션을 추가할 수 있습니다. 프로젝트에서 최소한 옵트인할 수 있도록 toml.

일부 대상에 대해 lld로 전환했습니다. https://rust-embedded.github.io/blog/2018-08-2x-psa-cortex-m-breakage/

나는 wass를 위해 또한 믿습니까?

이 문제는 외부 lld 바이너리와 연결하고 rustc 자체에 내장된 내부 lld 지원과 연결하는 것을 모두 포함합니까? 아니면 전자만?

이 문제는 외부 lld 바이너리와 연결하고 rustc 자체에 내장된 내부 lld 지원과 연결하는 것을 모두 포함합니까? 아니면 전자만?

외부 lld 바이너리, IIUC.

@nnethercote 내부 링커 사용을 추적하는 데 또 다른 문제가 있습니까? 아니면 별도로 문제를 제기해야 하나요?

내부 링커 아이디어에 대해 들어본 적이 없습니다. 나는 그것에 대한 PR을 알지 못합니다.

https://github.com/rust-lang/rust/pull/57514 LLD를 사용하여 LLVM을 연결할 수 있는 기반을 마련했습니다.

아마도 처음에는 "기본"과 "야간 전용" 사이에 중간 지점이 있어야 하며, -Z와 같이 LLD를 사용하도록 선택하지만 안정적인 빌드에서 작동하도록 -Z를 사용하지 않습니다.

https://github.com/rust-lang/rust/pull/56351 추가 -C linker-flavor .

이 문제가 무엇을 추적하려는 것인지 명확하지 않습니다. "Microsoft의 도구 모음을 사용할 수 없을 때 -msvc 대상에 대한 LLD와 연결"과 같은 특정 문제가 발생하기 위해 이것을 닫는 것이 더 나은 것 같습니다.

나에게 이 문제는 모든 대상에 대한 기본 링커로 LLD를 활성화하는 것에 관한 것입니다. LLD는 매우 빠르고 링크 시간은 종종 컴파일 시간의 중요한 구성 요소이며 컴파일 속도는 영원한 문제이기 때문에 저는 그것을 원합니다.

FWIW BMO 에서 macOS 에서 버그를 제출했습니다. 분명히 그것은 WONTFIX입니다. 다른 플랫폼의 LLD가 다른 프로그램이고 macOS의 LLD가 지연된 개발로 인해 손상되었기 때문에 댓글에서 "LLD는 매우 빠름"만큼 간단하지 않은 것 같습니다.

@briansmith 는 다른 대상에 대해 이 상태를 추적하기 위한 전용 문제를 갖는 것이 좋지만 이것을 닫는 대신 메타버그로 전환할 수 있다는 점에 동의했습니다. 어떤 대상이 문제를 제기할 가치가 있는지 더 많이 알고 있는 사람이 있으면 언제든지 LLD 지원 상태에 대한 루프를 벗어났기 때문에 자유롭게 말씀해 주십시오.

LLD와의 연결이 문서화되어 있습니까? (Linux에서) rustc -C linker-flavor=ld.lld hello.rs 가 있지만 운이 좋지 않습니다. 나는 LLD가 우리의 LLVM 사본과 함께 배포되었다고 생각했는데, 내가 틀렸습니까? 나는 또한 apt를 통해 LLD를 설치하려고 시도했지만 rustc는 여전히 수수께끼입니다. 오늘 Rust 코드로 LLD를 시도하기 위해 취해야 할 단계는 무엇입니까?

@bstrie -C linker=rust-lld 인수를 추가로 전달해야 합니다.

화물과 함께 작동해야합니까? 녹과 화물의 최신 야간 빌드에서 빈 프로젝트를 빌드하려고 할 때 현재 다음 오류가 발생합니다.

$ RUSTFLAGS='-C linker=rust-lld' cargo build
   Compiling rust3 v0.1.0 (/home/carado/tmp/rust3)
error: linking with `rust-lld` failed: exit code: 1
  |
  = note: "rust-lld" "-flavor" "gnu" "-L" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.2ualxzb8lqn4ho3y.rcgu.o" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.32vfyq64cfbzv618.rcgu.o" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.4rbt3m5y8o8cl09t.rcgu.o" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.ben0932xzwyt64v.rcgu.o" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.fzsdnygvstiwzxo.rcgu.o" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.x0rq6ifodcf11zi.rcgu.o" "-o" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.1m259ox4uzrzk583.rcgu.o" "--gc-sections" "-pie" "-zrelro" "-znow" "-L" "/home/carado/tmp/rust3/target/debug/deps" "-L" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--start-group" "-Bstatic" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-44988553032616b2.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-607feef6be9150b2.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libbacktrace-a8dbf6d92401e34a.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libbacktrace_sys-9a4716f5e8a3e722.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-988a64d96b043c6d.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-cadd6177b8c6d586.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-8f1d8efc92b45369.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-1e76014677816767.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-cc28bce38cb195d9.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-4123e9e89add689a.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-4d259c17788c1fb5.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-9495dbda85bb8f16.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-793d0026c575805f.rlib" "--end-group" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-33c3162edae6574e.rlib" "-Bdynamic" "-ldl" "-lrt" "-lpthread" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-lutil"
  = note: rust-lld: error: unable to find library -ldl
          rust-lld: error: unable to find library -lrt
          rust-lld: error: unable to find library -lpthread
          rust-lld: error: unable to find library -lgcc_s
          rust-lld: error: unable to find library -lc
          rust-lld: error: unable to find library -lm
          rust-lld: error: unable to find library -lrt
          rust-lld: error: unable to find library -lpthread
          rust-lld: error: unable to find library -lutil
          rust-lld: error: unable to find library -lutil


error: aborting due to previous error

error: Could not compile `rust3`.

To learn more, run the command again with --verbose.

carado와 같은 오류가 발생합니다. "shoehorn" -L /usr/lib 링커 호출로 관리되지만 누락된 libs 목록이 libgcc 로 시스템의 어디에도 존재하지 않는 -lgcc 단축됩니다( libgcc_s.a ) 나는 이것이 일부 gnu-ism의 결과라고 생각하지만 그것을 고칠 방법을 알 수 없습니다.

@almindor RUSTFLAGS='-C linker=rust-lld -L /usr/lib -L /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0' 또는 이와 유사한 것을 시도하십시오. 경로는 배포판 및 컴파일러 버전에 따라 다릅니다.

위의 내 의견이 LLD를 사용하는 올바른 방법입니까? 모든 프로그램이 SIGSEGV 충돌하므로 작동하지 않습니다.

Reading symbols from target/debug/hello...
(gdb) show directories
Source directories searched: ~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/etc:$cdir:$cwd
(gdb) r
Starting program: target/debug/hello 

Program received signal SIGSEGV, Segmentation fault.
core::ops::function::FnOnce::call_once{{vtable-shim}} () at /rustc/a7f28678bbf4e16893bb6a718e427504167a9494/src/libcore/ops/function.rs:231
(gdb) l
226     #[stable(feature = "fn_once_output", since = "1.12.0")]
227     type Output;
228 
229     /// Performs the call operation.
230     #[unstable(feature = "fn_traits", issue = "29625")]
231     extern "rust-call" fn call_once(self, args: Args) -> Self::Output;
232 }
233 
234 mod impls {
235     #[stable(feature = "rust1", since = "1.0.0")] 
(gdb) info reg
rax            0x0                 0
rbx            0x0                 0
rcx            0x0                 0
rdx            0x0                 0
rsi            0x0                 0
rdi            0x0                 0
rbp            0x0                 0x0
rsp            0x7fffffffddb0      0x7fffffffddb0
r8             0x0                 0
r9             0x0                 0
r10            0x0                 0
r11            0x0                 0
r12            0x0                 0
r13            0x0                 0
r14            0x0                 0
r15            0x0                 0
rip            0x7ffff7ffc000      0x7ffff7ffc000 <core::ops::function::FnOnce::call_once{{vtable-shim}}>
eflags         0x10202             [ IF RF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0
(gdb) disassemble 
Dump of assembler code for function core::ops::function::FnOnce::call_once{{vtable-shim}}:
=> 0x00007ffff7ffc000 <+0>: mov    (%rdi),%rax
   0x00007ffff7ffc003 <+3>: mov    (%rax),%rdi
   0x00007ffff7ffc006 <+6>: jmpq   *0x11d4(%rip)        # 0x7ffff7ffd1e0
End of assembler dump.

여기까지 오는 사람에게 GCC 9 또는 Clang을 컴파일러로 사용하는 경우 마법의 주문은 RUSTFLAGS="-C link-arg=-fuse-ld=lld" cargo build 입니다. 또는 -C linker=clang 는 GCC 버전에 관계없이 작동해야 하므로 선호될 수 있습니다.

영구적으로 만들려면 특정 프로젝트의 ~/.cargo/config 또는 .cargo/config 에 추가할 수 있습니다.

[build]
rustflags = ["-C", "linker=clang"]
# rustflags = ["-C", "link-arg=-fuse-ld=lld"]

@lnicola는 GCC 9 또는 Clang을 CC로 사용할 때만 작동합니다.

@bstrie 이거 현재 상황이 어떤지 아세요? 앞으로 나아가는 데 방해가 되는 요소는 무엇입니까?

@mati865 오래된 GCC를 가진 사람들을 위한 대체 호출을 알고 계십니까?

@lnicola 내 모든 플랫폼에는 Clang + GCC 9가 있으며 호환되지 않는 컴파일러와 함께 사용하는 방법을 조사하지 않았습니다.

@jonhoo 나는 이 분야의 어떤 일에도 뒤지지 않습니다. 당신이 컴파일러 팀에 물어보고 싶을 것입니다.

나는 팀에 태그를 붙일 수 없다고 생각하고 그들에게도 과도한 소음을 일으키고 싶지 않습니다. 거기에서 누군가가 빠르게 살펴보도록 하는 가장 좋은 방법은 무엇이라고 생각합니까?

분류; @rust-lang/compiler 이 문제의 현재 상태를 아는 사람이 있습니까?

LLD가 Rust와 함께 작동하도록 관리하는 모든 사람을 위해 플랫폼 및 사용 중인 모든 컴파일러의 특정 버전에 대한 세부 정보를 추가로 포함할 수 있습니까? 여기에 나열된 조언에도 불구하고 작동하는 데 어려움을 겪는 사람들을 여전히 보고 있습니다.

위에 게시한 명령은 GCC 9.2.0 및 LLD 9.0.0이 설치된 Linux에서 작동합니다. 때때로 Windows에서도 작동한다고 생각하지만 -fuse=lld를 지원하지 않는 Windows용 GCC 9를 사용하는 사람을 본 적이 있습니다. 여기에 게시된 일부 링크에 따르면 MacOS에서는 시도해 볼 가치가 없습니다.

LLD가 Rust와 함께 작동하도록 관리하는 모든 사람을 위해 플랫폼 및 사용 중인 모든 컴파일러의 특정 버전에 대한 세부 정보를 추가로 포함할 수 있습니까? 여기에 나열된 조언에도 불구하고 작동하는 데 어려움을 겪는 사람들을 여전히 보고 있습니다.

고양이 /etc/system-release
Fedora 릴리스 30(서른)

참조 --버전
CC(GCC) 9.2.1 20190827(레드햇 9.2.1-1)

ld.lld --버전
LLD 8.0.0(GNU 링커와 호환)

이것이 도움이되기를 바랍니다.

하지만 -fuse=lld를 지원하지 않는 Windows용 GCC 9를 사용하는 사람을 보았습니다.

@lnicola
Windows GCC 9 빌드는 -fuse-ld=lld 를 지원합니다(지원하지 않도록 패치되었지만 누군가가 지원하는 이유는 무엇입니까?).
rust-mingw 구성 요소가 설치되었고 링커가 .cargo/config 에서 재정의되지 않았다고 가정합니다. 그런 식으로 Rustc는 시스템 대신 GCC 6을 선택했습니다.

Windows의 또 다른 문제는 LLD 9 및 이전 버전이 지원하지 않는 하드코딩된 링커 플래그 --enable-long-section-names 입니다(향후 지원할 계획 있음). 이 문제를 해결하려면 다음을 수행할 수 있습니다.

• 이 플래그를 제거하는 래퍼 생성
• 이 플래그를 no-op으로 허용하도록 LLD를 패치합니다.
• 이 플래그를 사용하지 않는 패치된 로컬 Rust 빌드를 사용하세요.

Windows의 또 다른 문제는 LLD 9 및 이전 버전이 지원하지 않는 하드코딩된 링커 플래그 --enable-long-section-names입니다(향후 지원할 계획 있음).

이 부분은 https://github.com/rust-lang/rust/pull/66257에 의해 수정되었습니다.
Windows-gnu 사용자는 -fuse-ld=lld 를 지원하는 C 컴파일러를 사용하기 위해 여전히 수동 작업을 해야 합니다.

@bstrie : 이것은 Windows-MSVC의 Stable 및 Nightly에서 작동하며 자세한 내용은 이 gamedev-wg 문제의 첫 번째 게시물: https://github.com/rust-gamedev/wg/issues/50

또 다른 데이터 포인트: rustc 자체를 빌드할 때 RUSTFLAGS="-C link-arg=-fuse-ld=lld" 하면 빠른 14코어 Linux 상자에서 연결 시간이 93초에서 41초로 단축됩니다.

@nnethercote : 설정 다르지는 linker=lld (예를 들어)을에 [target.x86_64-unknown-linux-gnu] 의 단면 config.toml ?

@Aaron1011 : 내 추측으로는 두 가지 접근 방식이 동일한 효과를 가질 수 있지만 직접 확인하지는 않았습니다.

@Aaron1011 소리가 나야 합니다. https://github.com/rust-lang/rust/issues/39915#issuecomment -538049306을 참조

@mati865
LLD를 링커로 사용하여 x86_64-pc-windows-gnu 에 rustc 빌드를 시도했습니까?

오늘 시도했는데 LLD가 빌드 중간에 멈추고 작업을 중지하거나 unknown argument: --version-script=... 대해 불평합니다.
LLD가 LLVM 연결에만 사용되는 경우에도 중단이 발생합니다.

[llvm]
use-linker = "lld"

도구 버전:

$ ld.lld --version
LLD 9.0.1 (https://github.com/msys2/MINGW-packages.git 5e3b8820ed9f04221affee4197e458aca2612e87) (compatible with GNU linkers)

$ gcc --version
gcc.exe (Rev2, Built by MSYS2 project) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

@petrochenkov 예, 몇 가지 해킹으로 빌드할 수 있습니다.

• LLD COFF 백엔드는 링커 스크립트를 지원하지 않지만 LD와 LLD는 모두 MSVC 스타일 .def 파일에서 괜찮습니다. 해결하기 쉬운
• LLD는 라이브러리가 lib (UNIX 세계의 표준)로 시작하기를 기대하지만 어떻게든 Rust는 모든 windows-* 대상에 대해 이를 수행하지 않았습니다: https://github.com/rust-lang/ 녹/블롭/9ebf47851a357faa4cd97f4b1dc7835f6376e639/src/libstd/sys/windows/env.rs#L4
  LD는 어느 쪽이든 상관하지 않으며 LLD 또는 Rust 측을 눌러 수정해야 하는지 모르겠습니다.

나는 여기에 몇 가지 미래 가능성을 기록하고 있습니다. 몇 가지 구현 노력이 필요하지만, 이것이 Rust 개발의 오랜 고충을 해결하는 데 도움이 될 것이라고 생각합니다.

• 외부에서 제공하는 lld를 사용하는 대신 Rustc 내에서 정적 라이브러리로 빌드하여 사용하십시오. 이를 통해 Rustc 자체에 더 긴밀하게 통합하고 기본 경험을 개선하며 미래의 가능성을 열어줍니다.
• 링커 명령으로 lld에 많은 경로 이름을 전달하는 대신 가상 파일 시스템을 사용하고 수행할 충분한 메모리 공간이 있을 때마다 디스크 IO를 사용하는 대신 메모리에서 메모리로 해당 데이터를 전달합니다. 더 큰 프로젝트의 경우 수백 또는 수천 메가바이트의 디스크 IO를 절약할 수 있으므로 컴파일 시간이 향상됩니다.

링커 명령으로 lld에 많은 경로 이름을 전달하는 대신 가상 파일 시스템을 사용하고 수행할 충분한 메모리 공간이 있을 때마다 디스크 IO를 사용하는 대신 메모리에서 메모리로 해당 데이터를 전달합니다. 더 큰 프로젝트의 경우 수백 또는 수천 메가바이트의 디스크 IO를 절약할 수 있으므로 컴파일 시간이 향상됩니다.

IO 대역폭의 문제만은 아닙니다. Windows와 같은 플랫폼에서, 특히 Windows Defender가 활성화된 경우 작업하려는 각 파일은 상당한 시간 패널티를 추가하고 Rust의 codegen 단위 모델은 크레이트가 수백 개의 작은 개체 파일로 분할되어 많은 컴파일을 빠르게 쌓을 수 있음을 의미합니다. 시각.

이 버그는 약간 엉망입니다. 그래서 이것을 앞으로 나아가고자 하는 사람들을 위해 현재 상황에 대한 간략한 요약에 최선을 다하겠습니다.

lld 란 무엇입니까?

두 가지 이유로 바람직한 llvm 프로젝트의 일부인 링커:

• 크로스 컴파일에 매우 친숙합니다(따라서 임베디드 대상에 중점을 둡니다).
• 그것은 매우 빠릅니다(종종 Gold의 절반 시간으로 실행 -- 연결은 큰 프로젝트(rustc, 서보 등)의 경우 몇 분이 걸릴 수 있으며 연결은 증분 빌드로 컴파일의 엄청난 %가 될 수 있으므로 이 런타임을 절반으로 줄이는 것은 큰 거래.)

오늘날 Rust가 lld로 하는 일

• Rust는 현재 대부분의 플랫폼에서 자체적인 lld 복사본을 rust-lld라고 부르는 바이너리로 제공합니다.
• Rust-lld는 많은 베어 메탈 타겟에서 기본적으로 사용됩니다.
• Rust-lld는 wasm에 기본적으로 사용됩니다.
• (?) "-C linker-flavor"를 사용하여 rust-lld를 사용하도록 명시적으로 요청할 수 있습니다.

더 많은 곳(예: 데스크탑 linux/mac/windows)에서 rust-lld를 사용할 때의 문제

• lld용 macOS(Mach-O) 백엔드가 중단되어 중단됨
  
  
  
  • 처음부터 다시 쓰기가 시작되었지만 아직 초기 단계입니다.
  
  
• linux/unix 플랫폼에서는 ld/lld를 직접 호출해서는 안 됩니다. 시스템 c 컴파일러(예: gcc)를 통해 링커를 호출해야 합니다. 이 컴파일러의 책임은 crt1.o와 같은 시스템 기호를 찾아 ld에 제공하는 것입니다. 이것은 우리가 "그냥" Rust-lld를 사용할 수 없다는 것을 의미합니다. 우리는 그것을 gcc/clang/무엇이든 공급해야 합니다. (우리는 이 시스템 기호 논리를 직접 구현하고 싶지 않습니다)
  
  
  
  • 일반적으로 링커를 경로로 제공할 수 없으며 C 컴파일러의 검색 경로에 "ld"로 삽입해야 합니다.
  
  
  • 또는 동일한 작업을 수행할 수 있지만 "ld.lld"로 삽입하고 "-fuse-ld=lld"를 전달합니다.
    
    
    
    
    
    • 이것은 중요할 수 있습니다. 분명히 lld는 "ld" 또는 "ld.lld"로 실행되고 있는지에 대한 clang 스타일의 바이너리 이름 감지를 수행합니다(조사 필요)
    
    
    
    • 불행히도 -fuse-ld=lld는 GCC 9의 일부일 뿐이므로 이를 사용하려면 기능/버전 감지가 필요할 수 있습니다(clang은 오랫동안 사용했습니다)
    
    
    
  
  
• 창 - MSVC는 좋은 모양 분명히하고, 백엔드에 녹 LLD를 사용하는 일부 제한된 지원을 갖고있는 것 같아요,하지만 난 여기에해야할 일들에 대한 불분명 해요.
• windows-mingw는 고대 GCC를 얻을 수 있다는 점을 제외하고는 linux/unix와 거의 같은 위치에 있는 것 같습니다. 그리고 pseudo-windows-linux가 제대로 테스트된 구성이 아니기 때문에 상황이 약간 불안정합니다.

또한 일반적으로 lld는 최신 버전이며 대부분의 OS에서 기본값이 아닙니다. 더 많은 곳에서 이것을 사용하기 시작하면 임의의 호환 버그가 거의 확실하게 나타날 것입니다.

두 플랫폼에서 기본적으로 (rust-)lld를 사용하는 데 집중하기 위해 두 개의 메타버그를 제출했습니다.

• #71515 - x64 Ubuntu 20.04 LTS(더 광범위하게는 모든 x64 ELF 플랫폼)
• #71520 - x64 MSVC 창

windows-msvc는 상태가 양호하고 백엔드에서 rust-lld 사용을 제한적으로 지원하지만 여기서 수행해야 할 작업이 무엇인지 잘 모르겠습니다.

LLD + windows-msvc 상태가 상당히 양호하며 현재 rustc 개발에 이 설정을 사용하고 있습니다.

lld-link 필요한 모든 지원은 rustc 백엔드에 있지만 https://github.com/rust-lang/rust/issues/68647 과 같은 버그가

• 이것은 중요할 수 있습니다. 분명히 lld는 "ld" 또는 "ld.lld"로 실행되고 있는지에 대한 clang 스타일의 바이너리 이름 감지를 수행합니다(조사 필요)

하지만 ld와 ld.lld는 같은 모드입니다: https://github.com/rust-lang/llvm-project/blob/rustc/10.0-2020-02-05/lld/tools/lld/lld. cpp (8.0-2019-01-16부터 동일)

• 불행히도 -fuse-ld=lld는 GCC 9의 일부일 뿐이므로 이를 사용하려면 기능/버전 감지가 필요할 수 있습니다(clang은 오랫동안 사용했습니다)

ld.lld는 ld와 동일하고 https://patches-gcc.linaro.org/patch/11148/ 에 따르면 -fuse-ld=lld의 유일한 변경 사항은 다음과 같은 경우 ld 대신 ld.lld를 실행하는 것입니다. 우리는 PATH 주입을 사용합니다. 괜찮을 것입니다. 나는 이것을 gcc 9+로 잠그는 것은 좋지 않다고 생각합니다. 데비안 안정 버전은 8.3만 있고 불스아이는 아마도 2021년까지 출시되지 않을 것입니다.

• windows-mingw는 고대 GCC를 얻을 수 있다는 점을 제외하고는 linux/unix와 거의 같은 위치에 있는 것 같습니다. 그리고 pseudo-windows-linux가 제대로 테스트된 구성이 아니기 때문에 상황이 약간 불안정합니다.

mingw-w64 6.0.0(2018-09-16 출시)에는 gcc 8.3.0이 있으며 -fuse-ld=lld가 없지만 여전히 상당히 새롭습니다. mingw-w64 7.0.0(2019-11-11 릴리스)에는 -fuse-ld=lld가 있는 gcc 9.3.0이 있습니다. 데비안 버스터(안정)는 6.0.0이고 불스아이(테스트)는 7.0.0입니다. 데비안 스트레치(oldstable)에는 gcc 6.3.0이 포함된 5.0.1만 있지만, gcc 6.3에 심각한 문제가 있는 경우 lld 지원을 위해 최신 데비안 안정을 요구하는 것이 합리적이라고 생각합니다.

두 플랫폼에서 기본적으로 (rust-)lld를 사용하는 데 집중하기 위해 두 개의 메타버그를 제출했습니다.

• #71515 - x64 Ubuntu 20.04 LTS(더 광범위하게는 모든 x64 ELF 플랫폼)
• #71520 - x64 MSVC 창

lld의 macOS(Mach-O) 포트 정보: https://github.com/rust-lang/rust/issues/39915#issuecomment -618726211 이후로 작동하거나 최소한 훨씬 더 나은 상태를 유지하고 있는 것 같습니다. 작성되었습니다!

이 LLVM 커밋을 사용하여 lld 빌드하고 tokio-rs/tracing에 대한 프로젝트별 링커로 설정했습니다. 그런 다음 nightly-x86_64-apple-darwin 에 대한 추적을 구축하고 모든 테스트를 성공적으로 실행했습니다. (디버그) 빌드 시간에 대해 특히 만족합니다.

• ld 를 사용하면 깨끗한 cargo build 에 35초가 걸렸습니다.
• lld 로 깨끗한 cargo build 는 20초가 걸렸습니다.

참고:

• 이 성능 수치는 32GB RAM과 8코어 i9가 탑재된 최근 MacBook Pro에서 나온 것입니다.
• lld와 Mach-O 에는 몇 가지 해결되지 않은 문제 가 있습니다.

@davidbarsky 멋지다! 호기심에 그 성능을 zld 와 비교하면 어떻습니까? ( https://github.com/michaeleisel/zld )

또한 열을 고려 했습니까? MBP는 특히 기본 팬 속도 프로필을 사용하여 매우 빠르게 열 조절에 들어갑니다. 달리기를 하기 전에 경첩 근처에 있는 기계 바닥이 만졌을 때 식을 때까지 기다리면 일관성을 유지하는 데 도움이 됩니다.

나는 Ubuntu 16 i686에서 그런 버그입니다.