Re: MPS: profiler

[Pip Cet <pipcet@protonmail.com>]

On Friday, June 21st, 2024 at 10:43, Eli Zaretskii <eliz@gnu.org> wrote:
> This is not what happens in this case, so let's stick to what we
> actually see, okay? It's complex enough.

Yes, it is.

> > The right thing to do, IMHO, is to let MPS know that it should block SIGPROF (and any other signals that might use managed memory) while handling SIGSEGV.
> 
> I disagree. MPS must be able to support programs compiled with
> "-gprof", so I don't believe SIGPROF should be blocked.

Only while handling SIGSEGV, of course.

> The handler
> is our code, so we should modify the handler not to do anything unsafe
> if SIGPROF happens while MPS is processing its SIGSEGV. That's a much
> more reliable fix, and one that will allow us to keep our profiling
> code.

Why are you suggesting that my "fix" (which, yes, is overly broad, we'd need to go through the signals to find all we can safely leave unblocked) requires any changes to the profiling code? As far as I can tell, it just works.

The main difference between the two approaches, both of which require meddling with MPS internals, is that if SIGPROF is blocked, it will be delivered with a delay after the SIGSEGV handler is done running. If the SIGPROF handler runs and doesn't do "anything unsafe", on the other hand, it can record the unusable signal but won't get a new one. I don't see a clear advantage of either, to be honest. Blocking signals, of course, is more reliable than "just knowing" we won't do anything unsafe.

Pip