Re: better assembly level debugging

[Phil Muldoon <pmuldoon@redhat.com>]

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