[Lazarus] Issuing debug commands from the ide.

Benito van der Zander benito at benibela.de
Fri Jun 1 22:04:23 CEST 2012


>
> But then, it is fair to say you are experienced with gdb.
> There are also lots of people starting on lazarus, who have not even 
> heard of gdb.
For those it can show a warning if they enter a command

And if having a debug windows, in which you can see the commands the IDE 
passes
to gdb, and then try your own, modified version of the commands,
is an amazing way to learn to use gdb.
> I already have code, that parses expressions, and might in future 
> prevent function calling.
Really?

Then it becomes impossible to read complex properties, and you need a 
way to run direct commands
even more!
>
> Anyway, we both have our points. And it doesn't seem to change. 
Well, that is a point, I can agree with

> BTW what about "thread apply" in gdb? 
Single stepping seems to be always applied to all threads.

(which causes the problems in my case )

> Because it is more user friendly, than having to goggle gdb and type 
> some commandline style stuff... 
User friendly as in "I have never seen a debugger before, but if I click 
that button, I can see what my program is doing"

But if you have some experience, it is not user friendly, if you can't 
do something, because the feature is simply not there,
and have to stop the debugging session, and restart the program with the 
cli gdb.
Or if you always have  to click that button, and can't automate it with 
a python script or by copying some gdb commands from clipboard.

gdb also has a great documentation with help, apropos or tab completion.

And if you don't find something, you can google for it.
There are a lot more references about gdb commands than Lazarus buttons.

E.g. if you google for "gdb view memory" , every result describes the 
"x" command.
If you google for "Lazarus view memory", you find a memory game, the 
haunting memory of a derby, and star trek.
If you hadn't told me that you can view memory dumps in the watch 
window, I would have never guesses that.
(and someone who doesn't know pascal, c++ and gdb, would never guess 
that you need a trailing ^ at the address).


On 06/01/12 20:52, Martin wrote:
> On 01/06/2012 19:37, Benito van der Zander wrote:
>>>
>>>
>>> I already pointed out, how easy you can upset the IDE-to-gdb 
>>> interface, if you issue the wrong command.
>> You said that, but I have never seen it happen.
> But then, it is fair to say you are experienced with gdb.
> There are also lots of people starting on lazarus, who have not even 
> heard of gdb.
>
>>
>> Althought gdb crashes sometime randomly, even without running own 
>> commands.
>>
>> And running arbitrary commands is not special, there are other things 
>> that upset gdb, just as well.
>>
>> function TEST: integer;
>> begin
>> while true do ;
>> end;
>>
>> Evaluate TEST() and the debugging is broken, until you call "reset 
>> debugger".
> I know. currently you can trigger function evaluation, even though 
> nothing is ready to deal with.
> I already have code, that parses expressions, and might in future 
> prevent function calling.
>
>>
>> And that might happen with all evaluations, just as likely as if you 
>> run direct commands.
>
> Yes, or trying to modify an ansistring => boom
>
> I didn't say that the debugger was perfect.
> That is no reason to add more pitfalls.
>
> Anyway, we both have our points. And it doesn't seem to change.
>
>
>
>>>
>>> Feel free to provide it as an installable package. 
>> Can a plugin even send commands to the debugger, if that define is 
>> not set?
>
> That part of the interface can be added permanently.
> The idea s to spilt the debugger and have packages.
>
> Then an interface would be created.
> But the relevant parts of the interface can be added and published as 
> soon as someone provides them
>
>>
>> And then you have the package, a new Lazarus version appears, and it 
>> doesn't work anymore...
>>> Though one question:
>>> I can see how you can (technically) change this while the debugger 
>>> is running.
>>> But isn't that to late. If your app crashes without that, and you 
>>> already started the debugger. Then would it not crash?
>>>
>> If the first breakpoint is hit, all threads are stopped anyways.
>> Only single stepping causes a problem
> Yes. I read up.
>
> BTW what about "thread apply" in gdb?
>
>>> Anyway if we have a list of such options, then they can be added as 
>>> feature request.
>> They could.
>>
>> But why maintain another list of options, if gdb already knows its 
>> options
>
> Because it is more user friendly, than having to goggle gdb and type 
> some commandline style stuff...
>
> -- 
> _______________________________________________
> Lazarus mailing list
> Lazarus at lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus




More information about the Lazarus mailing list