|query: debugging dynamically generated code debray@CS.Arizona.EDU (2003-10-27)|
|Re: query: debugging dynamically generated code email@example.com (2003-10-31)|
|Re: query: debugging dynamically generated code firstname.lastname@example.org (K.C. Shashidhar) (2003-10-31)|
|Re: query: debugging dynamically generated code email@example.com (James Cownie) (2003-11-08)|
|From:||firstname.lastname@example.org (Michael Tiomkin)|
|Date:||31 Oct 2003 23:06:20 -0500|
|Posted-Date:||31 Oct 2003 23:06:19 EST|
debray@CS.Arizona.EDU (Saumya K. Debray) wrote
> How to people go about debugging code that's being
> generated/transformed dynamically? (My one experience, using gdb, was
> painful at best -- e.g., if I didn't get my timing right, and the
> dynamically generated code overwrote a breakpoint, gdb would
> nevertheless insist that I had a breakpoint at that address and refuse
> to let me set another one at that location.)
> Given the amount of interest and activity in JIT compilers and dynamic
> code optimization in recent years, I expect there's a fair amount of
> experience with, and literature on, this topic (though citeseer didn't
> turn up anything obvious). I'd be grateful for any pointers.
Look for "debugging self-modifying code". There are a lot of
references about it, mostly claiming negative experience. In viruses
and program protection, the only purpose of self-modifying code is to
make it less comprehensible and debuggable.
A debugger that is capable to debug self-modifying code might run
much slower. For example, one of the solutions would be to make the
"code" pages read-only and the "data" pages not executable, to catch
all the writes and jumps to them, and to change the debugger data
which relates to these writes.
Return to the
Search the comp.compilers archives again.