Open itamarst opened 7 months ago
This would be great — I'm keen to use this as part of https://github.com/numbagg/numbagg
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.
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.
)
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.
Kinda seems like people ship their own lldb-mi
executable for this use case :cry:
Hello. What about reading memory with vm_read
call like py-spy do?
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.
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 ?
Hi @parmentelat, sorry, I am just seeing this now. I don't know what happened.
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.
Update:
lldb-mi
I need to set e.g. LLDB_DEBUGSERVER_PATH=/opt/homebrew/Cellar/llvm/18.1.8/bin/lldb-server
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.
UPDATE: This may take a while...
The problem
lldb
currently works.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
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.lldb-mi
in the wheel.lldb-mi
for Homebrew.Workaround
On macOS, use Docker, Podman, or a VM to get a Linux environment.