The GDB JIT Interface

bernsteinbear.com

71 points·surprisetalk··9 comments

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.

How do you know what the equivalent C is for the JIT assembly ?

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.

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.

https://wiki.python.org/moin/DebuggingWithGdb

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

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.

Unfortunately I need to debug other people’s code and don’t have control over what runtime they’re using :(

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.

Reply on news.ycombinator.com