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

[Benito van der Zander]

> 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. 
All the things the GUI can't do or need improvements are just reasons to 
merge your patch (or a similar one) into Lazarus!

I will advocate again and again for it...
> Things like the disassembly window, 
Yes, the disassembly window is great and I don't know any gdb based 
debugger that has it that nice.
(except Insight years ago, but that is not maintained anymore, doesn't 
work with a new gdb and has become useless)

But it is a new features, and we had to wait years for it.
With a direct interface, you could just have used "disassemble /rm ..." 
and use that as a workaround,
until the GUI is finished

(and it uses at&t syntax, is there any way to switch it to intel? for 
the cli there is...).
> - workaround for missing IDE feature (e.g. mem viewer, threads) 
But you don't know which IDE features are missing, until you need them.
And then it is too late to implement them.

> If it is put in the IDE it will need maintenance. Like any feature of 
> course. The fact that it needs maintenance an its own does not stop 
> any feature.
> But again, this can be expected to need lots of maintenance in 
> comparison to the benefits (averaged over all users) 

But it is a single feature that can be used for various things.

if it is implemented, it can replaces several other features only the 1% 
need,
and you save a lot of time, when you don't have to implement and 
maintain those!



On 06/01/12 21:35, Martin wrote:
> On 01/06/2012 19:57, Ludo Brands wrote:
>> 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. 
>
> And I appreciate that you take the time to do that.
>
> But this is not only about what gdb can or can not.  There is a wide 
> range of users. And a feature like this is suited for a very small 
> group of them.
> By comparison the dangers versus the benefits simply do not hold up. 
> (It does measured by the standard' of the top 1%, but not for the rest)
>
> Also (and that is why I mentioned the IDE parts) splitting this into :
> - workaround for missing IDE feature (e.g. mem viewer, threads)
> - features that are unlikely to have a frontend
>
> How many are in the 2nd category. I know for you there are some. But 
> for most users, this is not the case. If it was, then it would be a 
> feature that needed a front end (due to demand)
>
> If it is put in the IDE it will need maintenance. Like any feature of 
> course. The fact that it needs maintenance an its own does not stop 
> any feature.
> But again, this can be expected to need lots of maintenance in 
> comparison to the benefits (averaged over all users)
>
> I do not know if I will have the time. But from whatever time I have, 
> I'll set some apart to help you make a package interface. Then you can 
> provide it as yours, and maintain it yourself.
>
>>>> 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?
>
> For most people
> - byte, word, dword , qword
> - High/Low endian
> - maybe bytes per line (8, 16, 32)
> - maybe ascii or even utf8 representation
>
>
>
>>>>> 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.
> Not following: why can you not cut and paste? The new multiline view 
> is a memo, it allows to select and copy
>
> (there is a bug in trunk, that prevents keyboard from almost all 
> toolwindows. But that is not part of this topic)
>
>>   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.
> Well watches do have history and snapshots in the IDE.
>
> The cli is not that comfortable (maybe gdb does provide that, but more 
> work)
>
> And for one off evaluation, there is the "evaluate" window
>
>>
>>>> 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.
>>
>
> But thats beside the point? using a watch or the commandline => the 
> question of needing the address or name is the same.
>
>
>
> -- 
> _______________________________________________
> Lazarus mailing list
> Lazarus at lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus