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
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
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
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)
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
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
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