|How to study debugger internals ? firstname.lastname@example.org (Ripunjay Tripathi) (2010-03-13)|
|Re: How to study debugger internals ? email@example.com (Giridhar S) (2010-03-13)|
|Re: How to study debugger internals ? firstname.lastname@example.org (ioan) (2010-03-14)|
|Re: How to study debugger internals ? email@example.com (Ian Rogers) (2010-03-14)|
|Re: How to study debugger internals ? firstname.lastname@example.org (Jeremy Bennett) (2010-03-15)|
|Date:||Sun, 14 Mar 2010 05:59:36 -0700 (PDT)|
|Posted-Date:||15 Mar 2010 01:07:22 EDT|
On Mar 13, 5:16 pm, Ripunjay Tripathi <ripunjay.tripa...@gmail.com>
> Excuse me if the post is NOT in scope of the community.
> Want to study debuggers internals. Though I understand that they are
> very much platform dependent, knowledge of internals for gdb and dbx
> (for Intel/ARM) I believe should give me good understanding.
ptrace() provides the possibility to write a debugger that does not
rely on hardware tricks in the task of getting informed when its
debugged process enter a break-point.
A debugger also has to do other tasks such as knowing for the
application it debugs the address of each function, the address of
each global (not on stack) symbol. these may be resolved with
Also the source-code binutils may give answers:
I want to say that I am not sure if all the information I write here
is correct. ptrace() information should be correct. Also I don't know
how it would be best to start studying debuggers. And finally,
I only said about debuggers on linux because at the moment I only know
details on how debuggers can be built for this platform. My intuition,
however, is that on other platforms there should be support for
writing similar to ptrace().
Return to the
Search the comp.compilers archives again.