Martin Storsjö

> This has cropped up a few times now (#10762, and a couple of times on Discord). After #10634, the 'triplet' directory (ex, `/clang64/x86_64-w64-mingw32`) no longer exists, and after [#10651...

> I think I'd prefer looking for mingw-w64 header/library in default paths. Can you clarify a bit more in detail what you mean here? > That would allow one day...

@dscho - I've been told you might have some insight into these parts of the runtime

> (there was #8, not sure if related and if it was every applied upstream) Oh, awesome - without testing it myself yet, that does sound from the outset like...

> I am _really_ concerned about a change like this. It is _prone_ to break existing setups. Look e.g. at the lengths Git for Windows goes to quote things accurately...

> There is some oddity in `llvm-nm`: > > ``` > $ /clang64/bin/nm /d/tmp/r/src/CLANG32/build/i686-pc-windows-gnu/stage1/lib/rustlib/i686-pc-windows-gnu/lib/rsbegin.o | grep eh_frame > 00000000 R __ZN7rsbegin9eh_frames10mingw_init6P_INIT17hcac2d6c918db7f49E > 00000000 R __ZN7rsbegin9eh_frames10mingw_init8P_UNINIT17h565e94d416ee6b01E > 00000000 b __ZN7rsbegin9eh_frames3OBJ17hc37ee6dbaafc1617E >...

Ok, great! So unwinding mostly works, but here, it hits a stack frame where something goes wrong. That changes what we need to look for. Which function does this correspond...

> Unfortunately I couldn't find out what is under that failing address. > In all the good frames `frameInfo.handler` points to https://github.com/rust-lang/rust/blob/91f128baf7704a477ab7c499143a160fb069b3ad/library/std/src/personality/gcc.rs#L244 but for that one problematic frame neither GDB...

I have started looking at this now, and I have almost nailed it down, but not quite. I noticed that when running this test in wine, it didn't hit the...

(First commenting on a few things I noted mentioned here before.) > It's noted in the [readme of llvm-mingw](https://github.com/mstorsjo/llvm-mingw#pdb-support): > > > while implemented for aarch64, it doesn't seem to...