Good remark! I know nothing about dynlink, so we should indeed check with someone that does (Alain, Benoît Vaugon, or the warmly welcome educated volunteer). My limited understanding is that the existing code already doesn't care about dynliked code fragments, in the sense that it only reads events from the executable's debug section, and not anything that would come from dynlinked cmo's. If that interpretation is correct, then the new behavior is "not worse".

If we do have a way to take dynlinked code into account, the way to fix the caching would be to save a timestamp  when debug_info is saved, and re-do the computation (and cache) when the timestamp change. The timestamp could be something like the size of `caml_code_fragments_table`.