rustc - signal: 11, SIGSEGV: invalid memory reference when compiling a crate

[sundeep-kokkonda]

When the p384 crate compiling we are getting 'signal: 11, SIGSEGV: invalid memory reference' error. This issue is occurring on 32-bit architecture machines when doing DEBUG build.
Also, this issue is observed only when building this in Yocto. In rust tarball sources we couldn't reproduce the issue.

Below is the build command and error message.

**Build command:**
process didn't exit successfully: `rustc --crate-name p384 --edition=2021 /home/work/poky/build/tmp/work/core2-32-poky-linux/cargo/1.70.0-r0/rustc-1.70.0-src/vendor/p384/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 --cfg 'feature="arithmetic"' --cfg 'feature="default"' --cfg 'feature="digest"' --cfg 'feature="ecdh"' --cfg 'feature="ecdsa"' --cfg 'feature="ecdsa-core"' --cfg 'feature="pem"' --cfg 'feature="pkcs8"' --cfg 'feature="sha2"' --cfg 'feature="sha384"' --cfg 'feature="std"' -C metadata=d8c37f70a895ae9a -C extra-filename=-d8c37f70a895ae9a --out-dir /home/work/poky/build/tmp/work/core2-32-poky-linux/cargo/1.70.0-r0/build/target/i686-poky-linux-gnu/debug/deps --target i686-poky-linux-gnu -C linker=/home/work/poky/build/tmp/work/core2-32-poky-linux/cargo/1.70.0-r0/wrapper/target-rust-ccld -L dependency=/home/work/poky/build/tmp/work/core2-32-poky-linux/cargo/1.70.0-r0/build/target/i686-poky-linux-gnu/debug/deps -L dependency=/home/work/poky/build/tmp/work/core2-32-poky-linux/cargo/1.70.0-r0/build/target/debug/deps --extern ecdsa_core=/home/work/poky/build/tmp/work/core2-32-poky-linux/cargo/1.70.0-r0/build/target/i686-poky-linux-gnu/debug/deps/libecdsa-e85642649bf0e7c9.rmeta --extern elliptic_curve=/home/work/poky/build/tmp/work/core2-32-poky-linux/cargo/1.70.0-r0/build/target/i686-poky-linux-gnu/debug/deps/libelliptic_curve-df69f4c85eaa7a64.rmeta --extern sha2=/home/work/poky/build/tmp/work/core2-32-poky-linux/cargo/1.70.0-r0/build/target/i686-poky-linux-gnu/debug/deps/libsha2-98350f9e69a514c9.rmeta --cap-lints allow -L /home/work/poky/build/tmp/work/core2-32-poky-linux/cargo/1.70.0-r0/recipe-sysroot/usr/lib/rustlib/i686-poky-linux-gnu/lib --remap-path-prefix=/home/work/poky/build/tmp/work/core2-32-poky-linux/cargo/1.70.0-r0=/usr/src/debug/cargo/1.70.0-r0` (signal: 11, SIGSEGV: invalid memory reference)

**Error:**
{"artifact":"./out-dir/p384-d8c37f70a895ae9a.d","emit":"dep-info"}
{"artifact":"./out-dir/libp384-d8c37f70a895ae9a.rmeta","emit":"metadata"}
...
...
| /home/work/poky/build/tmp/work/core2-32-poky-linux/cargo/1.70.0-r0/recipe-sysroot-native/usr/lib/librustc_driver-62e98be45f5bb4e6.so(+0xae9eb3)[0x7fcf8b8e9eb3]
| /home/work/poky/build/tmp/sysroots-uninative/x86_64-linux/lib/libc.so.6(+0x376e0)[0x7fcf8aa976e0]
| /home/work/poky/build/tmp/work/core2-32-poky-linux/cargo/1.70.0-r0/recipe-sysroot-native/usr/lib/librustc_driver-62e98be45f5bb4e6.so(+0x2bff2d3)[0x7fcf8d9ff2d3]
| /home/work/poky/build/tmp/work/core2-32-poky-linux/cargo/1.70.0-r0/recipe-sysroot-native/usr/lib/librustc_driver-62e98be45f5bb4e6.so(+0x1ad9d61)[0x7fcf8c8d9d61]
| /home/work/poky/build/tmp/work/core2-32-poky-linux/cargo/1.70.0-r0/recipe-sysroot-native/usr/lib/librustc_driver-62e98be45f5bb4e6.so(+0x1ada845)[0x7fcf8c8da845]
| /home/work/poky/build/tmp/work/core2-32-poky-linux/cargo/1.70.0-r0/recipe-sysroot-native/usr/lib/librustc_driver-62e98be45f5bb4e6.so(+0x1adb402)[0x7fcf8c8db402]
| /home/work/poky/build/tmp/work/core2-32-poky-linux/cargo/1.70.0-r0/recipe-sysroot-native/usr/lib/librustc_driver-62e98be45f5bb4e6.so(+0x1adb402)[0x7fcf8c8db402]
| /home/work/poky/build/tmp/work/core2-32-poky-linux/cargo/1.70.0-r0/recipe-sysroot-native/usr/lib/librustc_driver-62e98be45f5bb4e6.so(+0x1adb402)[0x7fcf8c8db402]
|... <<< same above line repeated several times >>> ...
|...
|...
| /home/work/poky/build/tmp/work/core2-32-poky-linux/cargo/1.70.0-r0/recipe-sysroot-native/usr/lib/librustc_driver-62e98be45f5bb4e6.so(+0x1adb402)[0x7fcf8c8db402]
| /home/work/poky/build/tmp/work/core2-32-poky-linux/cargo/1.70.0-r0/recipe-sysroot-native/usr/lib/librustc_driver-62e98be45f5bb4e6.so(+0x1adb402)[0x7fcf8c8db402]
| error: could not compile `p384` (lib)

We've tried to fix the issue and below 2 ways are fixing the linking problem for this crate but it has some side effects on rest of the build.

1. From build command when the '-C debuginfo=2' option removed the linking is success for this package. (But the other crates are getting failed by some other errors referring the functions from this crate are not found in the scope. May be disabling the debug causing some missing info?)
2. By keeping '-C debuginfo=2' and by removing the features 'arithmetic, ecdh, ecdsa & ecdsa-core' also making the package to link successfully. (Is there any way I can tell cargo to remove these features from this package and it's depending packages alone?)

Is this the issue in p384 when using debug / with these features?
The same issue was raised here and the comments mentions that this could be an issue with rust also. Will it be an issue with rust compiler?

[Noratrieb]

I can't reproduce this locally in a new crate with cargo add p384 and cargo build. What's your rustc -vV and p384 version and configuration. Can you share a simple project that reproduces the issue?

[sundeep-kokkonda]

Here is the rustc -vV output:

rustc 1.70.0 (90c541806 2023-05-31) (built from a source tarball)
binary: rustc
commit-hash: 90c541806f23a127002de5b4038be731ba1458ca
commit-date: 2023-05-31
host: x86_64-unknown-linux-gnu
release: 1.70.0
LLVM version: 16.0.2

Crate p384 package details from Cargo.toml:

[package]
edition = "2021"
rust-version = "1.57"
name = "p384"
version = "0.11.2"

As I mentioned, this I cannot reproduce this on rust tarball sources outside our Yocto build environment. I trimmed this environment with p384 crate alone to reproduce the issue but that is more than 10G in size.

[Noratrieb]

If we can't reproduce it then we can't really help with anything. The backtrace looks like a stackoverflow somewhere, maybe you can debug from that.

[sundeep-kokkonda]

The crate rust-version = "1.57" and we are using rustc 1.70.0. Is there any compatibility should be there here b/w these versions?

[Noratrieb]

That's just the minimum supported version, it should not have any problems.

[jyn514]

As I mentioned, this I cannot reproduce this on rust tarball sources outside our Yocto build environment.

that makes it sound like your build environment is causing the crash. i'd inspect things like CC, LD_LIBRARY_PATH, CFLAGS environment variables to see if there's anything that could be affecting the build. getting a backtrace of the segfault using gdb might also be useful.

[workingjubilee]

The crate rust-version = "1.57" and we are using rustc 1.70.0. Is there any compatibility should be there here b/w these versions?

In general, Rust aims to be completely "forward compatible". Future rustcs should compile the same code, though they may emit differing results (so runtime values of programs, if they depend on certain details, are subject to change, in some cases). So there are crates with an effective rust-version of 1.13 or so which still build with Rust 1.71.

I should note that we have a very hard time doing anything sensible in the case of resource exhaustion, however... there is somewhat of a catch-22 here where you have to be able to finish running the compiler before that stability promise comes into effect, and we don't promise exact resource usage of the compiler. We try to make it work to run ordinary builds on 32-bit though.

[saethlin]

I tried building the p384 crate in a variety of configurations and the most peak memory I can get is about 300 MB. So it seems very unlikely to me that just compiling p384 can reproduce the problematic situation.

Even if I were willing to work with Yocto, how would I reproduce this? You mentioned that this doesn't reproduce "outside our Yocto build environment" well okay, suppose I'm signing up for a real journey here: How would I reproduce your Yocto build environment and run whatever build you're running that causes this crash?

[sundeep-kokkonda]

@saethlin Add below lines in shell script and run, the issue will get reproduced. The issue will occur only with 32-bit machines Debug build.

#!/bin/sh

git clone git://git.yoctoproject.org/poky
cd poky
source ./oe-init-build-env
sed -i '27s/#MACHINE/MACHINE/' ./conf/local.conf
sed -i '39s/MACHINE/#MACHINE/' ./conf/local.conf
sed -i '40 a\DEBUG_BUILD = "1"' ./conf/local.conf

bitbake cargo

[saethlin]

My fresh clone from that script doesn't have a conf/local.conf so those lines do not do anything.

It looks like you are trying to build rustc and LLVM from source, on a 32-bit system. And based on DEBUG_BUILD = "1" perhaps you are trying to do a debug build of both. I am shocked that this does not segfault earlier.

[sundeep-kokkonda]

@saethlin Execute it via a shell script, it will reproduce the issue. If you are cloning manually then the conf file will be in .../poky/build/conf/local.conf. The build directory will be created after sourcing the environment in the cloned poky directory with command source ./oe-init-build-env

[saethlin]

I can reproduce a segfault on x86_64. The backtrace in gdb points to this stack frame repeating:

#2557 0x00007fb3d9eeb55b in llvm::AsmPrinter::emitDwarfDIE(llvm::DIE const&) const [clone .localalias] ()
   from /home/ben/poky/build/tmp/work/core2-32-poky-linux/cargo/1.70.0-r0/recipe-sysroot-native/usr/lib/librustc_driver-62e98be45f5bb4e6.so

I'd like to try building a reproducer that doesn't first need to compile gcc, LLVM, and rustc. Where is the target file for i686-poky-linux-gnu?

[sundeep-kokkonda]

The .../build/tmp/work/core2-32-poky-linux/cargo/1.70.0-r0/rust-targets/ will have i686-poky-linux-gnu.json & x86_64-unknown-linux-gnu.json files.

[workingjubilee]

Oh, it died while emitting debuginfo. lol. of course.

[jaskij]

So, from another person using Rust in Yocto

@sundeep-kokkonda

• You are using unreleased version of Yocto, which doesn't have much in the way of working guarantees. Can you try with a released branch? Although that'll be 1.68.2
• Why are you building Cargo for target? AFAIK it isn't tested at all.
• Does the issue persist if you bitbake cargo-native?

@saethlin @workingjubilee to add more context:

• OP is trying to cross-compile Cargo from x86_64 to x86, which I'm not sure currently works upstream, and most likely isn't tested in Yocto.
• Yocto is a gigantic memory hog, which usually pressures memory a lot, so it might be exposing some extremely rare race
• Yocto will build everything from source. From GCC for the host onwards.
• @saethlin mentions it looks like a stack overflow, and paths in Yocto are longer than in any other build system I've seen. And every single path is absolute. Just the build directory is 90 characters for me. When compiling C or C++ code, I've had error messages where just the compiler call didn't fit on a 2k screen.
• @saethlin you're wrong in that OP is building on a 32-bit system, the core2-32 is the target architecture. The architecture for the build system was not mentioned yet, although it defaults to x86_64.
• Worth noting, although outdated, is the README for meta-rust - a drop-in Yocto layer with Rust (which is different from the reference layer Sundeep is using)
• FWIW, I tried to build Cargo under my own Yocto setup, for AArch64, and had no issues.

[workingjubilee]

void	emitDwarfDIE (const DIE &Die) const
	Recursively emit Dwarf DIE tree.

@saethlin It seems likely the "build from source, with debuginfo" part is a key element here, unfortunately, as this is exactly the kind of thing you call if you want to blow the stack, given a sufficiently large DWARF structure to emit.

[jyn514]

that's an llvm function, so it seems very unlikely we'd be able to fix this upstream. i think we should close this as wontfix and Sundeep / jaskij can decide whether to report it upstream to llvm or not.

[saethlin]

As far as I can tell, this is successfully building LLVM with -Og. If I am correct in that, it makes sense that LLVM has rampant stack usage when compiled with minimal optimizations.

[jaskij]

I'm not running into this issue, I'm only here because I was asked to ;) FWIW, compiling Cargo for the target is somewhat outside of Yocto's design goals anyway.

It might be worth pinging @kraj with this, he's done a lot of LLVM and Rust work for Yocto and might have some insight.

[sundeep-kokkonda]

@jaskij I am able to reproduce the issue with 1.68.2 rust and bitbake cargo-native is success only the issue while building with cargo target build.
In the disassembly file as mentioned by @workingjubilee the llvm::AsmPrinter::emitDwarfDIE(llvm::DIE const&) const function is at issue address location. So, can we say this function is buggy when used with Debug mode? Is there any llvm expert can confirm?

[zmb3]

I'm seeing something similar with 1.75.0 and the wasm32-unknown-unknown target, which was working fine with 1.71.1.

Does this look like the same issue?

error: rustc interrupted by SIGSEGV, printing backtrace

/usr/local/rustup/toolchains/1.75.0-aarch64-unknown-linux-gnu/bin/../lib/librustc_driver-0db24dd631adfab6.so(+0xa87588)[0xffff78f82588]
linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0xffff810d481c]
/usr/local/rustup/toolchains/1.75.0-aarch64-unknown-linux-gnu/bin/../lib/librustc_driver-0db24dd631adfab6.so(+0x3542f4c)[0xffff7ba3df4c]

### cycle encountered after 3 frames with period 4
/usr/local/rustup/toolchains/1.75.0-aarch64-unknown-linux-gnu/bin/../lib/librustc_driver-0db24dd631adfab6.so(+0x35439b4)[0xffff7ba3e9b4]
/usr/local/rustup/toolchains/1.75.0-aarch64-unknown-linux-gnu/bin/../lib/librustc_driver-0db24dd631adfab6.so(+0x35439b4)[0xffff7ba3e9b4]
/usr/local/rustup/toolchains/1.75.0-aarch64-unknown-linux-gnu/bin/../lib/librustc_driver-0db24dd631adfab6.so(+0x35439b4)[0xffff7ba3e9b4]
/usr/local/rustup/toolchains/1.75.0-aarch64-unknown-linux-gnu/bin/../lib/librustc_driver-0db24dd631adfab6.so(+0x35437b8)[0xffff7ba3e7b8]
### recursed 62 times

/usr/local/rustup/toolchains/1.75.0-aarch64-unknown-linux-gnu/bin/../lib/librustc_driver-0db24dd631adfab6.so(+0x35439b4)[0xffff7ba3e9b4]
/usr/local/rustup/toolchains/1.75.0-aarch64-unknown-linux-gnu/bin/../lib/librustc_driver-0db24dd631adfab6.so(+0x35439b4)[0xffff7ba3e9b4]
/usr/local/rustup/toolchains/1.75.0-aarch64-unknown-linux-gnu/bin/../lib/librustc_driver-0db24dd631adfab6.so(+0x35439b4)[0xffff7ba3e9b4]
/usr/local/rustup/toolchains/1.75.0-aarch64-unknown-linux-gnu/bin/../lib/librustc_driver-0db24dd631adfab6.so(+0x35439b4)[0xffff7ba3e9b4]
/usr/local/rustup/toolchains/1.75.0-aarch64-unknown-linux-gnu/bin/../lib/librustc_driver-0db24dd631adfab6.so(+0x35439b4)[0xffff7ba3e9b4]

note: rustc unexpectedly overflowed its stack! this is a bug
note: maximum backtrace depth reached, frames may have been lost
note: we would appreciate a report at https://github.com/rust-lang/rust
error: could not compile `p384` (lib)

Caused by:
  process didn't exit successfully: `/usr/local/rustup/toolchains/1.75.0-aarch64-unknown-linux-gnu/bin/rustc --crate-name p384 --edition=2021 /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/p384-0.13.0/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no -C codegen-units=1 -C debuginfo=1 --cfg 'feature="alloc"' --cfg 'feature="arithmetic"' --cfg 'feature="default"' --cfg 'feature="digest"' --cfg 'feature="ecdh"' --cfg 'feature="ecdsa"' --cfg 'feature="ecdsa-core"' --cfg 'feature="pem"' --cfg 'feature="pkcs8"' --cfg 'feature="sha2"' --cfg 'feature="sha384"' --cfg 'feature="std"' -C metadata=d5a3b1be4b8c16e8 -C extra-filename=-d5a3b1be4b8c16e8 --out-dir /go/src/github.com/gravitational/teleport/target/wasm32-unknown-unknown/release/deps --target wasm32-unknown-unknown -L dependency=/go/src/github.com/gravitational/teleport/target/wasm32-unknown-unknown/release/deps -L dependency=/go/src/github.com/gravitational/teleport/target/release/deps --extern ecdsa_core=/go/src/github.com/gravitational/teleport/target/wasm32-unknown-unknown/release/deps/libecdsa-ac1ac24c64df15dc.rmeta --extern elliptic_curve=/go/src/github.com/gravitational/teleport/target/wasm32-unknown-unknown/release/deps/libelliptic_curve-342fbee3b669a41e.rmeta --extern primeorder=/go/src/github.com/gravitational/teleport/target/wasm32-unknown-unknown/release/deps/libprimeorder-c5eb78873066dc18.rmeta --extern sha2=/go/src/github.com/gravitational/teleport/target/wasm32-unknown-unknown/release/deps/libsha2-f5561fa2abd68f8c.rmeta --cap-lints allow` (signal: 11, SIGSEGV: invalid memory reference)
warning: build failed, waiting for other jobs to finish...
error: rustc interrupted by SIGSEGV, printing backtrace

/usr/local/rustup/toolchains/1.75.0-aarch64-unknown-linux-gnu/bin/../lib/librustc_driver-0db24dd631adfab6.so(+0xa87588)[0xffffa813e588]
linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0xffffb029081c]
/usr/local/rustup/toolchains/1.75.0-aarch64-unknown-linux-gnu/bin/../lib/librustc_driver-0db24dd631adfab6.so(+0x3542f4c)[0xffffaabf9f4c]

### cycle encountered after 3 frames with period 4
/usr/local/rustup/toolchains/1.75.0-aarch64-unknown-linux-gnu/bin/../lib/librustc_driver-0db24dd631adfab6.so(+0x35439b4)[0xffffaabfa9b4]
/usr/local/rustup/toolchains/1.75.0-aarch64-unknown-linux-gnu/bin/../lib/librustc_driver-0db24dd631adfab6.so(+0x35439b4)[0xffffaabfa9b4]
/usr/local/rustup/toolchains/1.75.0-aarch64-unknown-linux-gnu/bin/../lib/librustc_driver-0db24dd631adfab6.so(+0x35439b4)[0xffffaabfa9b4]
/usr/local/rustup/toolchains/1.75.0-aarch64-unknown-linux-gnu/bin/../lib/librustc_driver-0db24dd631adfab6.so(+0x35437b8)[0xffffaabfa7b8]
### recursed 62 times

/usr/local/rustup/toolchains/1.75.0-aarch64-unknown-linux-gnu/bin/../lib/librustc_driver-0db24dd631adfab6.so(+0x35439b4)[0xffffaabfa9b4]
/usr/local/rustup/toolchains/1.75.0-aarch64-unknown-linux-gnu/bin/../lib/librustc_driver-0db24dd631adfab6.so(+0x35439b4)[0xffffaabfa9b4]
/usr/local/rustup/toolchains/1.75.0-aarch64-unknown-linux-gnu/bin/../lib/librustc_driver-0db24dd631adfab6.so(+0x35439b4)[0xffffaabfa9b4]
/usr/local/rustup/toolchains/1.75.0-aarch64-unknown-linux-gnu/bin/../lib/librustc_driver-0db24dd631adfab6.so(+0x35439b4)[0xffffaabfa9b4]
/usr/local/rustup/toolchains/1.75.0-aarch64-unknown-linux-gnu/bin/../lib/librustc_driver-0db24dd631adfab6.so(+0x35439b4)[0xffffaabfa9b4]

[saethlin]

If you are using the rustc/cargo distributed via rustup, no this is not the same problem.

[OTLabs]

I am building cargo-c v0.9.29 (Alpine Linux, musl, rust v1.75.0) and it fails for p384 on 32-bit architecture machines (x86, armhf, and armv7) when doing debug build (cargo test --frozen):

thread 'opt cgu.0' has overflowed its stack
fatal runtime error: stack overflow
   Compiling gix-path v0.10.1
   Compiling gix-validate v0.8.1
   Compiling gix-chunk v0.4.5
   Compiling gix-quote v0.4.8
   Compiling gix-bitmap v0.2.8
   Compiling gix-config-value v0.14.1
   Compiling tracing v0.1.40
   Compiling cargo-util v0.2.8
   Compiling tracing-subscriber v0.3.18
error: could not compile `p384` (lib)
Caused by:
  process didn't exit successfully: `rustc --crate-name p384 --edition=2021 /home/buildozer/.cargo/registry/src/index.crates.io-1cd66030c949c28d/p384-0.13.0/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 --cfg 'feature="alloc"' --cfg 'feature="arithmetic"' --cfg 'feature="default"' --cfg 'feature="digest"' --cfg 'feature="ecdh"' --cfg 'feature="ecdsa"' --cfg 'feature="ecdsa-core"' --cfg 'feature="pem"' --cfg 'feature="pkcs8"' --cfg 'feature="sha2"' --cfg 'feature="sha384"' --cfg 'feature="std"' -C metadata=d48e9e764fb55950 -C extra-filename=-d48e9e764fb55950 --out-dir /builds/otlabs/aports/community/cargo-c/src/cargo-c-0.9.29/target/debug/deps -L dependency=/builds/otlabs/aports/community/cargo-c/src/cargo-c-0.9.29/target/debug/deps --extern ecdsa_core=/builds/otlabs/aports/community/cargo-c/src/cargo-c-0.9.29/target/debug/deps/libecdsa-68dead954bb0c335.rmeta --extern elliptic_curve=/builds/otlabs/aports/community/cargo-c/src/cargo-c-0.9.29/target/debug/deps/libelliptic_curve-93b2b72621b28a06.rmeta --extern primeorder=/builds/otlabs/aports/community/cargo-c/src/cargo-c-0.9.29/target/debug/deps/libprimeorder-600e8e0bdac7d173.rmeta --extern sha2=/builds/otlabs/aports/community/cargo-c/src/cargo-c-0.9.29/target/debug/deps/libsha2-8d315e9be62eebd9.rmeta --cap-lints allow -Clink-arg=-Wl,-z,pack-relative-relocs` (signal: 6, SIGABRT: process abort signal)
warning: build failed, waiting for other jobs to finish...

Could it be related?

[saethlin]

Maybe? I cannot reproduce this problem, but I suspect you're using your own rustc/LLVM not the one distributed by rustup.

Unfortunately I think your best bet is to file a bug with LLVM; I hope that the problem you're running into just has to do with having a differently-optimized LLVM build than rustup distributes. Our builds apply a lot of optimization that might have the side effect of reducing its stack consumption enough that we can build this crate.

And even if someone in Rust did reproduce this issue by building their own LLVM... even from the little bit of information here I don't think it's likely that this situation can be fixed in this repo.

[jieyouxu]

I'm going to close this issue because there doesn't seem like much we can do from rustc's side.

[rwmacleod]

LLVM issue for anyone interested: llvm/llvm-project#76920