I noticed that folks have been working on code generation lately. Any chance it might be possible to implement some of the opcodes required to get debugging working (step, break, etc)?
I seem to recall someone indicating it wasn't a terribly difficult task, but it's clearly beyond my understanding of the problem.
Bill
Actually, a much better solution would be to implement the JIT-debug info generation supported by gdb (including variable mapping etc).
This should make it possible to simply debug using gdb, with symbols.
This can be done using a plugin with GDB 7.5+ (I think) http://playingwithpointers.com/archives/633
or the old JIT registration API from GDB 7.0: http://sourceware.org/gdb/current/onlinedocs/gdb/JIT-Interface.html http://llvm.org/docs/DebuggingJITedCode.html
Doing it using a plugin seems to be the way to go, since that could also handle things like priting of pike values, etc.
That would probably help with viewing of stacktraces and variable data, but wouldn't opcodes still be needed to actually control stepping and breakpoints in the app itself?
I guess it's possibly worth mentioning that I have a long-standing bounty available for tasks that lead to viable debugging options; so far there hasn't been much interest, though that's not surprising given that the pool of possible developers is rather small :)
Bill
On Wed, 13 Jun 2012, Per Hedbor () @ Pike (-) developers forum wrote:
Actually, a much better solution would be to implement the JIT-debug info generation supported by gdb (including variable mapping etc).
This should make it possible to simply debug using gdb, with symbols.
This can be done using a plugin with GDB 7.5+ (I think) http://playingwithpointers.com/archives/633
or the old JIT registration API from GDB 7.0: http://sourceware.org/gdb/current/onlinedocs/gdb/JIT-Interface.html http://llvm.org/docs/DebuggingJITedCode.html
Doing it using a plugin seems to be the way to go, since that could also handle things like priting of pike values, etc.
That would probably help with viewing of stacktraces and variable data, but wouldn't opcodes still be needed to actually control stepping and breakpoints in the app itself?
No, GDB will handle the breakpoints natively.
Which is why it would be so convenient.
Basically, when you tell GDB to break at foo.pike:398, it will look up the address in the JIT:ed code for that line, and then insert a normal breakpoint there.
There is no need at all for breakpoint, step etc opcodes.
Those are only needed if you want to do debuggin in the virtual machine, and not in the actual machine (basically, inserting breakpoints is exactly what GDB is doing, but it is doing so in the native generated code)
Ah, I well that is pretty interesting, and presumably you'd automatically get easy access to the whole gdb ecosystem as well.
Presumably such a thing would be a fairly involved effort, though, correct?
Bill
On Wed, 13 Jun 2012, Per Hedbor () @ Pike (-) developers forum wrote:
That would probably help with viewing of stacktraces and variable data, but wouldn't opcodes still be needed to actually control stepping and breakpoints in the app itself?
No, GDB will handle the breakpoints natively.
Which is why it would be so convenient.
Basically, when you tell GDB to break at foo.pike:398, it will look up the address in the JIT:ed code for that line, and then insert a normal breakpoint there.
There is no need at all for breakpoint, step etc opcodes.
Those are only needed if you want to do debuggin in the virtual machine, and not in the actual machine (basically, inserting breakpoints is exactly what GDB is doing, but it is doing so in the native generated code)
Bill Welliver wrote:
Ah, I well that is pretty interesting, and presumably you'd automatically get easy access to the whole gdb ecosystem as well.
Presumably such a thing would be a fairly involved effort, though, correct?
The interface can be rather minimal, if I recall correctly. But I guess nobody has looked into this since?
The interface can be rather minimal, if I recall correctly. But I guess nobody has looked into this since?
The interface is indeed rather minimal, it basically only allows setting and removal of breakpoints and memory reading (and writing) (1).
But GDB still expects an architecture it can understand when it reads and write memory using it, specifically the object files mapped in RAM must have debug information GDB understands (say, dwarf3).
It is the GDB process that does the translation from address to source lines etc, so using the remote debugger does not really help. If our compiler generated in-ram elf objects it would work just as well to debug locally, without any addition of a gdbserver interface.
Something that _would_ work, but be insanely fiddly, would be to fake the remote api memory layout etc so that it looks like we have compiled ELF objects. But that seems harder than making sure we actually do have them.
1: https://sourceware.org/gdb/onlinedocs/gdb/Remote-Protocol.html
— Per Hedbor
pike-devel@lists.lysator.liu.se
-
Bill Welliver -
Per Hedbor -
Per Hedbor () ＠ Pike (-) developers forum -
Stephen R. van den Berg