> 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.
>
That is why I preferred to bring it up on the mailing list instead of
posting the patch immediately on mantis.
> 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.
>
I understand that making a gui for a debugger is not easy at all and it is
difficult to please everybody. Things like the disassembly window, the
source code window, watches are invaluable compared to what the command line
gdb offers. However, trying to fit everything the command line can do in the
straight jacket of the GUI is artificially clipping the power of the
debugger. Weeding through arbitrary memory or some of the other usage
examples I gave are not the standard usage for most users. So I wouldn't
expect that any of it would be accomodated in a GUI and feel a little bit
sorry that this exchange turned into a list of things the IDE can't do or
needs improvement in. It just started as wanting to share a personal, small
effort to combine the advantages of the GUI and the flexibility of the CLI.
> > 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
> Yes a proper viewer must be written for this.
>
A proper viewer would mean: all possible formats gdb supports + unit size +
arbitrary data lengths + showing symbols gdb returns. Is that worth it?
> > 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?
In this case it was an object I instantiated myself and the interface
pointers were returned from a call to queryinterface on the object and on
its IUnknown.
> >> 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 ^ )
>
Ugly is not a problem. Not being able to do a simple cut and paste of the
address is what hurts. When looking at a chain of pointers like in the
example, the downside of watches is also that or you create a watch for
every pointer and you delete them all after use or you re-use the same watch
but then you don't have any history in case you picked the wrong address in
a table. In both cases a lot of clicking to simulate something that can be
done easily when using cli commands.
>
> > 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.
>
Still need to know the exact spelling of the symbol. The same symbol can be
uppercase or "original" case, sometimes depending on wheter you have debug
info or not (exported symbol). Plus the name mangling for class methods.
Example: procedure _FPC_WinMainCRTStartup;stdcall;public name
'_WinMainCRTStartup'; is known to the debugger as _FPC_WINMAINCRTSTARTUP
(stabs info available). I find myself using 'info function' frequently to
find or disambiguate functions.
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
