| commit | 866424a5d4d9d3e7fce8a179f080ee0ceb254ebc | |
| author | strange <kawk256@gmail.com> | |
| Wed, 16 Dec 2009 20:59:01 +0000 (16 13:59 -0700) | ||
| committer | strange <kawk256@gmail.com> | |
| Wed, 16 Dec 2009 20:59:01 +0000 (16 13:59 -0700) | ||
| tree | d90711d71c7fc652b17e62ba8a06e50ec05949bc | treesnapshot (tar.gz zip) |
| parent | 01980517c348d4f35eb94f7a1baccd60ae50badd | commitdiff |
Just ran aesalon on a slightly larger executable than the test ones I've used.
Result: aesalon is too slow -- after 600 seconds of parsing the assembly, I
gave up and interrupted it. Therefore, the gdb interface, while fine for
demonstration purposes, is quite obviously not good enough. So . . .
Back to square one. Again. Perhaps if I implemented my own "debugger" using
ptrace and such? That would tie aesalon even more to POSIX-based platforms,
but frankly, I don't care that much. I could also just use objdump to get the
assembly rather than gdb, but that still means that it runs at gdb's speed or
less. How *do* graphical debuggers that display the content of all the
variables while the program is running work, anyhow? Probably just variable
objects and async mode.
I'll do some research.
Result: aesalon is too slow -- after 600 seconds of parsing the assembly, I
gave up and interrupted it. Therefore, the gdb interface, while fine for
demonstration purposes, is quite obviously not good enough. So . . .
Back to square one. Again. Perhaps if I implemented my own "debugger" using
ptrace and such? That would tie aesalon even more to POSIX-based platforms,
but frankly, I don't care that much. I could also just use objdump to get the
assembly rather than gdb, but that still means that it runs at gdb's speed or
less. How *do* graphical debuggers that display the content of all the
variables while the program is running work, anyhow? Probably just variable
objects and async mode.
I'll do some research.
| src/interface/gdb/Controller.cpp | diffblobblamehistory |