Fix use-after-free bugs in debuginfo

[pchintalapudi]

Fixes #44562
Fixes #44947

This is achieved by making the debug info global variables a part of the JIT engine, which should leak their memory with our JIT rather than being destroyed on process exit.

We also do the following as part of the move:

1. Consolidate all of the debug info global variables into one large struct
   1. This sequences all of the destructor orderings, and ties their lifetimes together for easier analysis.
2. Make debug info threadsafe
   1. This is achieved by locking around the data structures within the debug info registry

[pchintalapudi]

We now use std::greater<size_t> instead of revcomp

[DilumAluthge]

@pchintalapudi Does this fix #44562?

[pchintalapudi]

I'm hoping for that, but I want to get results for macos before confirming that.

[DilumAluthge]

Once you have the builders and testers passing, we can check the Buildkite CI logs for both the macOS x86_64 tester and the macOS Apple Silicon tester, and see if there are still any segfaults in the logs.

[DilumAluthge]

Looks like the Windows builders are failing with: /cygdrive/c/buildbot/worker/package_win32/build/src/debuginfo.cpp:246:9: error: 'create_PRUNTIME_FUNCTION' was not declared in this scope

[pchintalapudi]

I'll tackle that and the analyzegc failures once the mac tester finishes, just to see if it works.

[DilumAluthge]

You'll find the macOS x86_64 tester in the Test group - look for the job named test x86_64-apple-darwin.

The macOS Apple Silicon tester is in the Allow Fail group - look for the job named test aarch64-apple-darwin.

[pchintalapudi]

Macos tests look successful for 07eb7bf

[DilumAluthge]

macOS x86_64 also looks segfault free on f0b06f8: https://buildkite.com/julialang/julia-master/builds/11193#aa5af690-dc6a-4023-a4f6-0e1115f2397c

[pchintalapudi]

Looks like Mac+aarch64 is also clean: https://buildkite.com/julialang/julia-master/builds/11193#7749e3f8-a7fd-4f3f-bed1-30a0496e6540

[vtjnash]

This seems a good approach. Thanks!

[pchintalapudi]

@vtjnash Do you have suggestions on how to fix the analyzegc failures? I tried to mark getDebugInfoRegistry with JL_NOTSAFEPOINT, but that didn't stop the analyzer from complaining about the call.

[vtjnash]

getDebugInfoRegistry should be marked JL_NOTSAFEPOINT, but you might need to teach the analyzer how to find properties of CxxMember function calls, since finding their decl site is different from finding the decl target for a basic C function call.

[pchintalapudi]

Now that the analyzegc check is passing, I think we can merge this into master if tests pass and no segfaults are observed on macos?

[pchintalapudi]

@DilumAluthge do we need to rerun the windows testers? I haven't seen these kinds of errors before.

[DilumAluthge]

Let me try rebooting the Windows VMs.

[DilumAluthge]

@vtjnash If CI passes, is this good to merge from your point of view?

[vtjnash]

yep, seemed to be good to go

[maleadt]

Doesn't this need a backport? Otherwise we'll still have #44562 on 1.8. (cc @KristofferC)

[DilumAluthge]

It would be great to get this backported.