Attempt macOS support

[itamarst]

trafficstars

UPDATE: This may take a while...

The problem

1. Profila currently uses GDB to get stacktraces, using the Machine Interface ("MI") protocol.
2. GDB doesn't work on macOS ARM, only lldb currently works.
3. lldb-mi is third-party tool supposedly compatible with GDB MI, but not readily available on macOS. E.g. VS Code plugins will ship it themselves.

Potential solutions

1. Switch to non-debugger method of getting stack traces; need something that relies on debuginfo in the way debuggers do. Initial experiments have failed, this is why there hasn't been profiling support for Numba until now! But will keep trying.
2. Ship lldb-mi in the wheel.
3. Convince some kind soul to package lldb-mi for Homebrew.
4. GDB adds support for macOS ARM.
5. Figure out a different way than MI to control lldb. The remote server protocol (same as GDB?) might work. Or there's https://pypi.org/project/hilda/ which either might be usable or might be a reasonable example. https://lib.rs/crates/lldb is another potential solution.

Workaround

On macOS, use Docker, Podman, or a VM to get a Linux environment.

[max-sixty]

This would be great — I'm keen to use this as part of https://github.com/numbagg/numbagg

[itamarst]

I recommend doing brew install gdb and just trying it, it might work! But I'll also try and poke at it tomorrow.

Also note that Profila doesn't support parallel Numba. I guess I'll file an issue for that too.

[max-sixty]

I recommend doing brew install gdb and just trying it, it might work!

(fyi no luck yet — gdb: The x86_64 architecture is required for this software.)

[itamarst]

Hm. Googling suggests gdb doesn't support Mac Silicon/ARM machines, as of 2022 at least.

There's apparently a third-party lldb tool that supports that same MI protocol that gdb does, lldb-mi, and it might ship on Macs (it doesn't on Ubuntu, alas), so I'll try that next.

[itamarst]

Kinda seems like people ship their own lldb-mi executable for this use case :cry:

[Dementiy]

Hello. What about reading memory with vm_read call like py-spy do?

[itamarst]

py-spy doesn't work with Numba... Profila relies on the debug info that Numba creates for gdb/lldb if NUMBA_DEBUGINFO env variable is set to non-zero value. This is apparently not something py-spy (or most tools) can use, I am not certain why.

So vm_read and something like libunwind is a start, but it doesn't actually solve the problem of how to map memory addresses to JITed code.

[parmentelat]

hey there

I'm trying to use profila on a mac/intel from the context I was hoping for it to work out of the box, however I am running into this

$ python -m profila annotate -- one.py p3x20 2 2
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "~/miniconda3/envs/exact-cover-py/lib/python3.12/site-packages/profila/__main__.py", line 126, in <module>
    main()
  File "~/miniconda3/envs/exact-cover-py/lib/python3.12/site-packages/profila/__main__.py", line 118, in main
    annotate_command(args)
  File "~/miniconda3/envs/exact-cover-py/lib/python3.12/site-packages/profila/__main__.py", line 79, in annotate_command
    stats = asyncio.run(main())
            ^^^^^^^^^^^^^^^^^^^
<snip>
  File "~/miniconda3/envs/exact-cover-py/lib/python3.12/site-packages/profila/_gdb.py", line 141, in run_subprocess
    await _read_until_done(process)
  File "~/miniconda3/envs/exact-cover-py/lib/python3.12/site-packages/profila/_gdb.py", line 90, in _read_until_done
    raise ProcessExited()
profila._gdb.ProcessExited

I do have gdb installed and this is under sonoma 14.4

$ gdb --version
GNU gdb (GDB) 14.2
<snip>

$ arch
i386

$ uname -a
Darwin zoi 23.4.0 Darwin Kernel Version 23.4.0: Wed Feb 21 21:44:31 PST 2024; root:xnu-10063.101.15~2/RELEASE_X86_64 x86_64

am I doing something wrong ?

[itamarst]

Hi @parmentelat, sorry, I am just seeing this now. I don't know what happened.

[itamarst]

So I'm testing lldb-mi, and every sample it takes is 100+ ms on my Linux machine using lldb 14. That's very slow. But I guess it's better than nothing, and maybe newer versions are faster. So this may be kinda sorta viable.

[itamarst]

Update:

• On both Linux and macOS with lldb-mi I need to set e.g. LLDB_DEBUGSERVER_PATH=/opt/homebrew/Cellar/llvm/18.1.8/bin/lldb-server
• On Linux lldb-mi works, on macOS it... doesn't. It's unclear why, lldb-mi just gives this error: '{'type': 'result', 'message': 'error', 'payload': {'msg': 'Connection shut down by remote side while waiting for reply to initial handshake packet'}, 'token': None}'

So putting this aside again for now.