Tudor Brindus

There seem to be some conflicts with the base branch, could you please try rebasing to resolve them?

Out of curiosity, is opening `/dev/cpu_dma_latency` and writing 0 to it sufficient to prevent the issues for you, or did you have to disable turbo entirely? I haven't encountered issues...

Would this be served by having `-multi-snapshot` mode just work like this? The current implementation leaves large gaps in the tracefile, so isn't too useful. The format could be something...

Hmm... from the wrapper's warning message, I'm assuming this is a `perf` patched for hugetext/BOLT, which is not open-source for us to try reproducing with? I think it's doing something...

OCaml integers are 63 bits by default (one tag bit for the garbage collector), so trying to parse the offset in `tan@plt+0xfffffffffef9b000` fails. It's possible to get around this locally...

I tried compiling a slightly modified [`demo.c`](https://github.com/janestreet/magic-trace/blob/master/demo/demo.c) with: { perf 5.2, perf 5.15, perf 5.17 } × { mold 1.2.1, ld 2.38 } × { gcc 12 } × {...

Thanks for reporting. This looks a lot like https://github.com/janestreet/magic-trace/issues/196, which we haven't been able to reproduce on our end. Could you share any more information about how to reproduce this?

Closing to dedup with https://github.com/janestreet/magic-trace/issues/196, if you have any more information about this issue please reply there.

I'm not sure which I like more: - a `-serve-port` flag, or - starting from 8080 and trying increasing port numbers until we find one we can bind to

Ref also `-immediate-stop` from https://github.com/janestreet/magic-trace/pull/79.