Stream: project-ffi-unwind

Topic: mixing -Clto and -Cpanic=abort


view this post on Zulip nikomatsakis (Sep 02 2021 at 18:21):

I have questions about LTO and panic=abort that maybe @Alex Crichton or @bjorn3 can answer

view this post on Zulip nikomatsakis (Sep 02 2021 at 18:21):

Based on reading #project-ffi-unwind > weekly meeting ...

view this post on Zulip nikomatsakis (Sep 02 2021 at 18:21):

I think the problem is that we have some kind of LLVM pass that triggers with -Clto

view this post on Zulip nikomatsakis (Sep 02 2021 at 18:21):

which goes and forcibly converts all invoke calls to not invoke

view this post on Zulip nikomatsakis (Sep 02 2021 at 18:21):

presumably because we may be mixing code from -Cpanic=unwind which was using invoke

view this post on Zulip nikomatsakis (Sep 02 2021 at 18:22):

and the problem here is that there may be some calls to "C-unwind" FFI calls

view this post on Zulip nikomatsakis (Sep 02 2021 at 18:22):

which may indeed unwind, because we can't stop them

view this post on Zulip nikomatsakis (Sep 02 2021 at 18:22):

and now the personality function change that @bjorn3 proposed doesn't activate

view this post on Zulip nikomatsakis (Sep 02 2021 at 18:22):

because we are using an LLVM call and not an invoke

view this post on Zulip nikomatsakis (Sep 02 2021 at 18:22):

is that all correct?

view this post on Zulip nikomatsakis (Sep 02 2021 at 18:22):

if so, is a plausible fix to add some sort of annotation to any call that we generate which is calling a "C-unwind" FFI function

view this post on Zulip nikomatsakis (Sep 02 2021 at 18:22):

and to modify the -Clto pass not to modify invokes with that annotation?

view this post on Zulip nikomatsakis (Sep 02 2021 at 18:23):

I'm not sure how one adds such annotations :) I'm just assuming it's possible

view this post on Zulip Alex Crichton (Sep 02 2021 at 18:28):

For this there's not anything baked into LLVM itself, rather rustc manually adds nounwind to all function calls (which will later get optimized from invoke to call by LLVM). The compiler runs the custom pass here which is defined here. Put another way, this is all custom rustc code, so one fix is "just delete all that". This is somewhat nontrivial though in that it's not clear how many, if any, users are relying on the behavior today

view this post on Zulip Alex Crichton (Sep 02 2021 at 18:28):

LLVM afaik here has no issues, it's all about what we're giving LLVM

view this post on Zulip Alex Crichton (Sep 02 2021 at 18:30):

The problem is that I think, fundamentally, that pass can't be "updated" in some way that adjusts for the new C-unwind ABI. We can't differentiate at the LLVM-IR-level what's a Rust function and what isn't. With that, though, we may be able to patch all the IR to do the right thing (by recording which symbols can actually unwind and having them continue to unwind, just going to landing pads that abort)

view this post on Zulip nikomatsakis (Sep 02 2021 at 18:31):

@Alex Crichton I don't get why the pass can't be adjusted

view this post on Zulip nikomatsakis (Sep 02 2021 at 18:31):

this is kind of what I was proposing:

view this post on Zulip nikomatsakis (Sep 02 2021 at 18:32):

don't we only have to modify the exact call to a ffi-unwind function?

view this post on Zulip nikomatsakis (Sep 02 2021 at 18:32):

(and then it will enter our personality function and abort?)

view this post on Zulip Alex Crichton (Sep 02 2021 at 18:32):

as I type this out I think it may be able to get updated, yeah

view this post on Zulip Alex Crichton (Sep 02 2021 at 18:33):

I haven't thought much about specifics though

view this post on Zulip Alex Crichton (Sep 02 2021 at 18:33):

but in theory there could be a set of symbols that are the extern "C-unwind" functions, both defined in Rust and in C), and any calls to those functions, with LTO, would immediately go to a landing pad that aborts.


Last updated: Jan 26 2022 at 08:02 UTC