Better support for dynamically adjusting the filter

[RalfJung]

Feature Request

Motivation

I am trying to debug a nasty issue in Miri. I need to trace what happens during a certain part of the execution of the program. However, the issue starts billions of steps into the execution -- if I set the log-level to info, which enables per-step tracing in Miri, I will get hundreds of gigabytes of log before the interesting part of the execution even starts. So I'd like to start with no logging, and then when a certain event happens (programmatically detected inside the interpreter), I'd like to call some function in the tracing API that enables logging starting now.

Proposal

Tracing already has this notion of "subscribers", but it doesn't let me swap out the global subscriber so this doesn't help. I can set a per-thread subscriber, but:

• It is forced to be active in a given "scope", which doesn't suit my usecase. The trigger for "start logging" will be somewhere deep inside one part of the interpreter, and then I want other parts of the interpreter to be logged.
• It makes me completely re-configure the subscriber, when all I really want is change the filter of the existing subscriber.

I have no idea what the best way is to achieve this. I barely know tracing. All I know is I can set filters, and I want the filter to change during execution -- or something that has the equivalent effect.

Cc @oli-obk

[davidbarsky]

I think you’d want to use tracing-subscriber’s reload module: https://docs.rs/tracing-subscriber/latest/tracing_subscriber/reload/index.html. Two things to note:

• You’d probably need to either need thread the reload::Handle around Miri (or, more likely) shove it into a globally-accessible static.
• Writing out the full type for a type from tracing-subscriber is not great. The .boxed() method will probably help.

[RalfJung]

Ah, yes that does seem interesting, thanks!