This was always too much work for not enough benefit. What I did in the case to debug into such cases, I constructed the C equivalent temporarily, compiled it on the fly also with -g, set the source to this file and could easily debug the function.
setheron 9 hours ago [-]
How do you know what the equivalent C is for the JIT assembly ?
rurban 9 hours ago [-]
Since I generate the asm part, generating the C part is easier.
I usually do just simple method JITs, which are C parts. Usually just calling an API method.
amelius 6 hours ago [-]
Related, is there a way to get better backtraces for a Python program, in GDB?
I.e., showing the function names as they exist in Python, where relevant, and otherwise just the C names.
Anyone know how to actually enable this for, say, v8? I’ve debugged Chrome compiled code without symbols and it’s miserable and I’d really like to not have to do that
torginus 4 hours ago [-]
I remember tinkering with the Chrome build system, and you can make it emit debug symbols but the compile time and memory use goes through the roof.
I work with CEF, and Spotify provides builds for the source, which have debug symbols, I think it's much more practical to use that.
torginus 4 hours ago [-]
I haven't really worked with the GDB source, but for GCC, I found that there was very little documentation (not for users but for developers), and even that was mostly outdated. This is in stark contrast to LLVM.
Rendered at 14:56:19 GMT+0000 (Coordinated Universal Time) with Vercel.
I usually do just simple method JITs, which are C parts. Usually just calling an API method.
I.e., showing the function names as they exist in Python, where relevant, and otherwise just the C names.
I work with CEF, and Spotify provides builds for the source, which have debug symbols, I think it's much more practical to use that.