Support macOS

Edits from Brennan:

I'm repurposing this issue to "support macOS". The original issue is below.

The main thing we need to do to support macOS is provide something like linux::collect_shared_objects for macOS. This can probably done using the functions documented in dyld(3).

Hi peeps,

I am looking for some guidance on how to run pprof on macos,

I have a rust app configured as follows:

1. app/Cargo.toml

[profile.release] 
lto = "thin"
debug = 1  # Line tables only.

tikv-jemalloc-ctl = { version = "0.5" }
tikv-jemalloc-sys = { version = "0.5", features = ["profiling"] }
tikv-jemallocator = { version = "0.5", features = ["profiling"] }

[target.'cfg(not(target_os = "macos"))'.dependencies]
jemalloc_pprof = "0.1.0"

2. conditionally add it to axum

    #[cfg(not(target_os = "macos"))]
    {
        router = router.route("/debug/pprof/heap", get(web::pprof::pprof_heap));
    }

3. port-forward on the pod

4. run go tool pprof http://localhost:9200/debug/pprof/heap locally, it throws:

Fetching profile over HTTP from http://localhost:9200/debug/pprof/heap
Local symbolization failed for app (build ID 9d67e10139bad60c021451c99d19ec33b08f8a67): open /usr/local/bin/app: no such file or directory
Local symbolization failed for libpthread.so.0 (build ID 255e355c207aba91a59ae1f808e3b4da443abf0c): open /lib/x86_64-linux-gnu/libpthread.so.0: no such file or directory
Local symbolization failed for libc.so.6 (build ID a3780b0b8a5bf5876e31d16b0a9d8fc6ba69a1f2): open /lib/x86_64-linux-gnu/libc.so.6: no such file or directory
Some binary filenames not available. Symbolization may be incomplete.
Try setting PPROF_BINARY_PATH to the search path for local binaries.
http post http://localhost:9200/debug/pprof/symbol: server response: 404 Not Found

the mechanics of how all this connects is quite hazy for me, but it looks like app binary does not have symbols and that is causing the local symbolization to fail,

question: is that due to #[cfg(not(target_os = "macos"))]? pprof works for the cpu profile, indicating the app binary has the correct symbols *maybe?

btw, for testing, I've copied the binary locally, and open /usr/local/bin/app: no such file or directory was gone, the other two remained

Start by locating the existing linux::collect_shared_objects implementation and reviewing the macOS dyld(3) functions linked in the issue; app/Cargo.toml shows the target-specific setup from the original report. Done means macOS can provide the equivalent shared-object collection needed for heap-profile symbolization and the existing profiling workflow works there.