[Lazarus] RE : RE : Issuing debug commands from the ide.

Ludo Brands ludo.brands at free.fr
Fri Jun 1 18:32:28 CEST 2012


> In the "Debug output" window. Where all the gdb stuff is.
>

Ok found it.

> > Hence the x/20x $sp example.
> http://imagebin.org/214731
> 
> memory dump of $pc^
> 

I rarely use the watch window and hadn't explored the memory dump style.
Here is how x/40xw $sp is presented in my patched version:

>x/40x $sp
0x396fe08:   0x00000000   0x00634750   0x03e87d10   0x03e87d10
0x396fe18:   0x00426ff0   0x000cee18   0x00079b68   0x00634750
0x396fe28:   0x00703444   0x0062deb4   0x0396fe60   0x0396fe0c
0x396fe38:   0x00426ee2   0x0396fe24   0x0396feb0   0x00000001
0x396fe48:   0x00000001   0x0396fe98   0x0396feb0   0x0053047c
0x396fe58:   0x000cee18   0x000cee18   0x0396fec0   0x00419e1e
0x396fe68:   0x00000000   0x0041c37c   0x0396fe58   0x0396fe98
0x396fe78:   0x00000001   0x00000000   0x00634750   0x00703444
0x396fe88:   0x0062deb4   0x0396fed8   0x0396fce8   0x0041c34e
0x396fe98:   0x00634750   0x00703444   0x0062deb4   0x0396fec0

The watch window (note also the little endianness making addresses even more
difficult to read):
0396FE08: 00 00 00 00 50 47 63 00 10 7d e8 03 10 7d e8 03 f0 6f 42 00 18 ee
0c 00 68 9b 07 00 50 47 63 00 44 34 70 00 b4 de 62 00 60 fe 96 03 0c fe 96
03 e2 6e 42 00 24 fe 96 03 b0 fe 96 03 01 00 00 00 01 00 00 00 98 fe 96 03
b0 fe 96 03 7c 04 53 00 18 ee 0c 00 18 ee 0c 00 c0 fe 96 03 1e 9e 41 00 00
00 00 00 7c c3 41 00 58 fe 96 03 98 fe 96 03 01 00 00 00 00 00 00 00 50 47
63 00 44 34 70 00 b4 de 62 00 d8 fe 96 03 e8 fc 96 03 4e c3 41 00 50 47 63
00 44 34 70 00 b4 de 62 00 c0 fe 96 03 6c fe 96 03 ee 9d 41 00 98 fe 96 03
28 ff 96 03 01 00 00 00 18 ee 0c 00 d8 fe 96 03 d8 82 41 00 00 00 00 00 18
ee 0c 00 00 00 00 00 18 ee 0c 00 40 ff 96 03 a3 e7 41 00 00 00 00 00 b4 de
62 00 00 90 fd 7f 44 34 70 00 b4 de 62 00 20 ff 96 03 e0 fd 96 03 38 28 54
00 e8 fe 96 03 00 00 00 00

The debug output window:

<x/40x $sp>
&"x/40x $sp\n"
~"0x396fe08:\t0x00000000\t0x00634750\t0x03e87d10\t0x03e87d10\n"
~"0x396fe18:\t0x00426ff0\t0x000cee18\t0x00079b68\t0x00634750\n"
~"0x396fe28:\t0x00703444\t0x0062deb4\t0x0396fe60\t0x0396fe0c\n"
~"0x396fe38:\t0x00426ee2\t0x0396fe24\t0x0396feb0\t0x00000001\n"
~"0x396fe48:\t0x00000001\t0x0396fe98\t0x0396feb0\t0x0053047c\n"
~"0x396fe58:\t0x000cee18\t0x000cee18\t0x0396fec0\t0x00419e1e\n"
~"0x396fe68:\t0x00000000\t0x0041c37c\t0x0396fe58\t0x0396fe98\n"
~"0x396fe78:\t0x00000001\t0x00000000\t0x00634750\t0x00703444\n"
~"0x396fe88:\t0x0062deb4\t0x0396fed8\t0x0396fce8\t0x0041c34e\n"
~"0x396fe98:\t0x00634750\t0x00703444\t0x0062deb4\t0x0396fec0\n"
^done

> > - tried to get to the VMT of a COM interface yesterday
> 
> You need to dig into FPC, to find the offset .
> 

But it is so much easier to look at the memory area the interface points to
directly. The debugger returns also symbol information when there is some
that gets lost in the evaluate or watch window. For example here is a short
session for an interface to an object implemented in TAbstractEventSink:

>x/8xw 0x03E781A4
0x3e781a4:   0x00067108   0x00629ae0   0x03e78178   0x00426ff0
0x3e781b4:   0x000cee18   0x00000000   0x00000000   0x00000000

>x/8xw 0x00067108   
0x67108:   0x007030b0   0x03e87e40   0x34a715a0   0x11d06587
0x67118:   0x20004a92   0x4dacc7af   0x00000001   0x03e78178

>x/8xw 0x007030b0   
0x7030b0 <VMT_$EVENTSINK_$$_TABSTRACTEVENTSINK>:   0x00000028   0xffffffd8
0x0062d9c0   0x00703118
0x7030c0 <VMT_$EVENTSINK_$$_TABSTRACTEVENTSINK+16>:   0x00000000
0x00000000   0x00000000   0x00703390

The <VMT_$EVENTSINK_$$_TABSTRACTEVENTSINK> is info that is lost when using
the watch window. I think you could also agree that the watch window is not
the most appropriate to do this exercise neither.

> 
> > - info fun with partial function names
> Not sure what you mean:
> But you know the debug inspector (context menu on watches) shows the 
> objects method (if they are avail)
>

I meant the gdb 'info function' command with regex parameter to find the
address of a function.

 
> > - set a breakpoint at non fpc code (dll exported symbols 
> for example)
> We have address breakpoints, you can set them in the disassembler.
> 

But how to find the address of for example a dll exported symbol?

Example:
>info function OpenURL
All functions matching regular expression \"OpenURL\":

Non-debugging symbols:
0x444a82ee  IEFRAME!OpenURL
0x444a82ee  OpenURL


> > Non of this is to debug the debugger.
> >
> 
> Right, there are features in gdb, that the IDE does not yet support 
> (e.g. attach/ detach)
> 
> Better to implement the features ....
> 
> But feel free to use that define
> 

Thanks. Now that I have made the patch I'll hang on to it. The debug output
window throws in a lot of what lazarus is doing with the debugger and the
useful information is easily scrolled away by new debug info (mouse hovering
over a variable, a single step, ...). It also slows down stepping a lot. 

Ludo











More information about the Lazarus mailing list