This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Feature Request


Not a huge fan of mailing lists, not sure I'm sending this to exactly
the right place but anyway here goes...

I am developing a Native Arm Forth compiler for an embedded Linux
device. This compiler can be though of as a JIT compiler in that the
opcodes it compiles are not written out to some separate object module
but are literally inserted directly into the existing compilers
process space.

This is causing me no end of grief regarding the debugging of said JIT
code because GDB flat refuses to simply disassemble and single step
any opcodes not associated with some debug info. There will never be
any debug information for the code being layed down by the compiler
because once the compiler is working NO debugger will ever be needed,
Forth simply does not require debuggers of this type.

Right now a debugger is needed but if I cannot reliably lay down
compiled code how can I expect to reliably lay down debug information
and pass this to the debugger I'm using?  This is a chicken/egg
problem.

So, I would like to request a feature that will allow GDB to simply
single step opcodes anywhere within the process space owned by the
application being debugged even if there is no debug symbols
associated with it.

I know GDB is open source but I stand a greater chance of being the
first man to land on the sun than I would have of ever making any
sense out of any of the GDB internals :)

Ty in advance (not holding my breath)

  Mark Manning

-- 
"When something can be read without effort,
great effort has gone into its writing."

-- Enrique Jardiel Poncela --


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]