* better assembly level debugging
@ 2011-05-02 15:34 Francois
2011-05-02 16:13 ` Phil Muldoon
0 siblings, 1 reply; 2+ messages in thread
From: Francois @ 2011-05-02 15:34 UTC (permalink / raw)
To: gdb
Hello
I'm trying to do some machine code-level debugging using GDB.
Basically, I'm debugging a C application that provides no debugging
symbol.
GDB works greatly, and I think a few customization could make it as
nice as the other popular debugging alternatives for this task (like
OllyDbg for Win32).
- defining labels
reverse engineering is very difficult without debugging symbols. It
would be very handy if I could (like on IDA or OllyDbg) define my own
labels. That would be for example user-defined symbols, which could be
used to get a nicer output.
For example
set label 0x402000 log_error
would define a new symbol "log_error". Further disassembly of "call
0x402000" instruction, or stepping near this address would give a
cleaner output.
- pretty printer for instructions
GDB could pretty print what it disassembles so that values of operands
are introspected (looking for strings or functions especially)
Let's take an example :
#include <stdio.h>
#include <wchar.h>
int main() {
int (*printIt) (const wchar_t*, ...) = wprintf;
const wchar_t* foo = L"foo 42";
printIt(foo);
}
compiled with g++ -o wide wide.cpp, I see:
=> 0x0000000000400690 <+4>: sub $0x10,%rsp
0x0000000000400694 <+8>: movq $0x400578,-0x10(%rbp)
0x000000000040069c <+16>: movq $0x4007ac,-0x8(%rbp)
...
which contains zero indication for reading.
I would expect
0x400578 to be commented as # <wprintf@plt> and
0x4007ac to be commented as # L"foo 42"
moreover, if compiled with g++ -o wide wide.cpp -fPIC, the first lines
above change to
=> 0x400680 <main+4>: sub $0x10,%rsp
0x400684 <main+8>: mov 0x1003fd(%rip),%rax # 0x500a88
0x40068b <main+15>: mov %rax,-0x10(%rbp)
0x40068f <main+19>: lea 0x106(%rip),%rax # 0x40079c
once again, we need to run
x/a 0x500a88
x/ws 0x40079c
to get an understandable disassembly.
Do you think these features could be integrated in GDB? If yes I could
send some code for review.
Francois
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: better assembly level debugging
2011-05-02 15:34 better assembly level debugging Francois
@ 2011-05-02 16:13 ` Phil Muldoon
0 siblings, 0 replies; 2+ messages in thread
From: Phil Muldoon @ 2011-05-02 16:13 UTC (permalink / raw)
To: Francois; +Cc: gdb
Francois <rigault.francois@gmail.com> writes:
> - defining labels
> reverse engineering is very difficult without debugging symbols. It
> would be very handy if I could (like on IDA or OllyDbg) define my own
> labels. That would be for example user-defined symbols, which could be
> used to get a nicer output.
> For example
> set label 0x402000 log_error
> would define a new symbol "log_error". Further disassembly of "call
> 0x402000" instruction, or stepping near this address would give a
> cleaner output.
I like the utility of this. I think you could probably write a large
amount of this in Python. If a label is just a location, that could
easily be stored in a Python list. You would have to teach the GDB
linespec code about parsing these utility labels though; that is an
internal GDB task. OTOH, I think there is a way to assign locations to
GDB vars from the command-line right now. I'm not sure.
> - pretty printer for instructions
> GDB could pretty print what it disassembles so that values of operands
> are introspected (looking for strings or functions especially)
>
> Let's take an example :
>
> #include <stdio.h>
> #include <wchar.h>
> int main() {
> int (*printIt) (const wchar_t*, ...) = wprintf;
> const wchar_t* foo = L"foo 42";
> printIt(foo);
> }
>
>
> compiled with g++ -o wide wide.cpp, I see:
> => 0x0000000000400690 <+4>: sub $0x10,%rsp
> 0x0000000000400694 <+8>: movq $0x400578,-0x10(%rbp)
> 0x000000000040069c <+16>: movq $0x4007ac,-0x8(%rbp)
> ...
>
> which contains zero indication for reading.
> I would expect
> 0x400578 to be commented as # <wprintf@plt> and
> 0x4007ac to be commented as # L"foo 42"
>
I think you probably write a Python based pretty-printer for this. I'm
not sure if 0x400... in the assembly output is a value or just some text
GDB prints. If not, you could probably add some hooks in the
disassembler to call the Python pretty-printer code before printing the
address?
>
> Do you think these features could be integrated in GDB? If yes I could
> send some code for review.
My 2 cents, I think these would be great features, regardless of whether
you choose to implement them in pure C or a Python hook/C approach.
I am not a maintainer though, wait for thoughts from them first!
Cheers,
Phil
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2011-05-02 16:13 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-02 15:34 better assembly level debugging Francois
2011-05-02 16:13 ` Phil Muldoon
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).