If anyone here has thoughts on how to fix the problem described here: https://github.com/rust-lang/rust/pull/67502#issuecomment-580305566 I'd love to hear them
the static is
static FOO: unsafe extern "C" fn(*mut u8) -> ! = ... fwiw
Try inserting a load here: https://github.com/Mark-Simulacrum/rust/blob/opt-catch/src/librustc_codegen_ssa/mir/block.rs#L187
maybe the problem is really with eh_unwind_resume itself, and the fallback case of the "declare_fn" being wrong now (since there's no such fn)
Well you're definitely missing a load instruction. You can't call a static, you need to get the function pointer out of it first.
hm, what does get_static do then?
I'm not too familiar with the codegen API, so I can't really tell you what the correct method to use on
i.e. what is it returning?
A pointer to the static?
oh, so I thought it was a load
but I guess a pointer makes more sense
It still looks wrong. The second half of
rust_eh_unwind_resume as a function pointer if it can't find the lang item (which is the case when compiling libcore). You need to change that half to declare
rust_eh_unwind_resume as a static and return a pointer to it.
That way you can just have an unconditional load in
I think the code right now is correct, just "wrong" in the sense that it's not as nice as it could be, right? I'm thinking that unconditionally returning a function pointer from
eh_unwind_resume is the right thing to do, and then we don't need a static, right?
(in the second case)
That won't work since the value is cached. You need to emit a load instruction at every use point.
hm, right, that makes sense -- we can't stick a load instruction into nowhere, I guess?
bit sad to have to load from memory every time, but I guess maybe the optimizer can optimize away the load too
It should be able to optimize it away with LTO since the static is a constant.
is this done with weak linkage or something?