Stream: t-compiler

Topic: -fasynchronous-unwind-tables


nikomatsakis (Dec 06 2018 at 21:09, on Zulip):

Anyone know anything about -fasynchronous-unwind-tables? Do we expose this option in compiling rustc? In particular, i'm trying to use perf but none of the --call-graph options seem to be giving me the data I want (even with frame pointers enabled). @Alex Crichton tells me that maybe I need to enable "asyncronous unwind tables" since sampling can occur at any point in time, and our dwarf data may not be prepared for that.

nikomatsakis (Dec 06 2018 at 21:09, on Zulip):

@nagisa seems like something you might know :)

nagisa (Dec 06 2018 at 21:46, on Zulip):

I don’t know about asynchronous unwind tables, but it also seems weird to me that you would need it, unless you are profiling unwinding...

Alex Crichton (Dec 06 2018 at 23:04, on Zulip):

Looks like it's just the uwtable attribute in LLVM, set here in rustc -- https://github.com/rust-lang/rust/blob/118e052d84157a675649fe640e3d56f264475a3a/src/librustc_codegen_llvm/attributes.rs#L162-L181

Alex Crichton (Dec 06 2018 at 23:05, on Zulip):

some targets have it on by default like windows, but there's currently no CLI flag to turn it on by default

Alex Crichton (Dec 06 2018 at 23:05, on Zulip):

I think @nikomatsakis for better debuginfo we'd need to add a CLI flag to turn it on by default for the compilation at hand

nikomatsakis (Dec 07 2018 at 09:36, on Zulip):

@Alex Crichton hmm but that code says:

if !cx.sess().no_landing_pads() || cx.sess().target.target.options.requires_uwtable { .. }

I presume no_landing_pads means -Cpanic=abort? In that case, aren't we enabling this attribute for the compiler anyway, since we don't build with that option?

nagisa (Dec 07 2018 at 10:59, on Zulip):

You can make yourself a custom target that derives the primary target and sets "requires_uwtable"?

nagisa (Dec 07 2018 at 11:00, on Zulip):

if no_landing_pads are specified, the attribute is not added because it has no value whatsoever then

nagisa (Dec 07 2018 at 11:00, on Zulip):

(given that there are no unwind targets)

nikomatsakis (Dec 07 2018 at 11:27, on Zulip):

well, that's not clear

nikomatsakis (Dec 07 2018 at 11:27, on Zulip):

in particular, for profiling, we may need to walk the stack back at arbitrary spots

nikomatsakis (Dec 07 2018 at 11:27, on Zulip):

and I gather that this attribute is relevant then (at least @Alex Crichton thought so)

nikomatsakis (Dec 07 2018 at 11:27, on Zulip):

so we may want a way to force it on even if there is no unwinding

Alex Crichton (Dec 07 2018 at 13:22, on Zulip):

Conclusion was that LLVM/Clang don't actually implement asynchronous-unwind-tables, unlike gcc

Last update: Nov 12 2019 at 17:00UTC