tracer: load initial maps from /proc/<pid>/maps

[fw-immunant]

Fixes #315. That said, this is atop #595 which causes problems as I haven't finished debugging the tracer's hangs.

The tracer hangs have now been resolved. 🎉

No longer atop #595. But it may be the case that there are lingering tracer hangs.

[oinoom]

Maybe not directly related to this PR, but I was looking through the track memory map given your hang issues, and noted that I didn't see handling in the syscall-exit path for WAIT_GROUP_STOP, WAIT_SIGSEGV, WAIT_SIGNALED, WAIT_CONT, and WAIT_PTRACE_FORK. Hopefully this helps. I wonder about the last one and if that's the one that's causing the hangs

[fw-immunant]

Maybe not directly related to this PR, but I was looking through the track memory map given your hang issues, and noted that I didn't see handling in the syscall-exit path for WAIT_GROUP_STOP, WAIT_SIGSEGV, WAIT_SIGNALED, WAIT_CONT, and WAIT_PTRACE_FORK. Hopefully this helps. I wonder about the last one and if that's the one that's causing the hangs

This is intentional, but I've made it clearer in the commit "track_memory_map: print in more error cases" (landed as 73f7100).

[fw-immunant]

<comment moved along with relevant commit to appropriate PR>

[fw-immunant]

If #661 lands first, then this PR will need a rebase and should be sure to include a commit reverting "memory-map: allow [pkey_]mprotect of unknown memory".

EDIT: I've put this atop #661 (with said revert) anyways, see next comment.

[fw-immunant]

Hmm, this is giving "attempting to pkey_mprotect unmapped memory" errors even as-is. I'll see if rebasing atop #661 solves things.

EDIT: Wonderful, looks like it does.

[fw-immunant]

This is now ready for review.

[fw-immunant]

CI hit a strange failure that I've reproduced on main and filed as #667. Since it occurs on main, it isn't an issue with this PR.