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

Martin lazarus at mfriebe.de
Fri Jun 1 19:07:46 CEST 2012

I am not arguing against you using your patch.  And if you want to 
distribute it, then fine.

Adding it to the IDE is out of question though.
To many dangers, and people will complain when they loose their debug 
session, because they did the wrong thing.

Also I am pointing out what can be done by the IDE already. Though 
admittedly some of it needs to be improved.
And if added proper, then everyone can use it.

On 01/06/2012 17:32, Ludo Brands wrote:
>>> 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
> 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

Yes a proper viewer must be written for this.

>>> - 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:

So where do you get the address?
Btw,  if you have the name, you can enter it as watch, and specify mem-dump

>> x/8xw 0x03E781A4
> 0x3e781a4:   0x00067108   0x00629ae0   0x03e78178   0x00426ff0
> 0x3e781b4:   0x000cee18   0x00000000   0x00000000   0x00000000
despite the fact that currently mem dumps are really ugly, you can also 
enter the address into a watch ("0x3e781a4^"), and get the mem dump there.

So again, it boils down to having a proper mem viewer
(well and removing the need for the ^ )

>> 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.

yes, that is missing. the ide doesnt look up addresses and tell you the 

>>> - info fun with partial function names
> 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?

I guess the address breakpoint could be extended to take symbol names too.

>   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.

yes its a memo... memo is slow

More information about the Lazarus mailing list