> 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 -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
