[Lazarus] Issuing debug commands from the ide.

[Benito van der Zander]

>
>
> 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". 
Omg, it's much worse.

That loop continues to run within gdb, and doesn't stop, if you call 
"reset debugger".

In fact, it doesn't even stop, if you close Lazarus.

Now my laptop has been running at 100°C for 3 hours, I hope it hasn't 
been damaged...



On 06/01/12 20: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.
>
> 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".
>
> And that might happen with all evaluations, just as likely as if you 
> run direct commands.
>
>> I recompile very frequently, and it never wet.
>> I always recompile from the Tools menu 
> I use "svn update; make clean all"
>
>> * Lazarus will never have direct support for all possible gdb 
>> commands. If you have added them all, there will be new ones in gdb
>> And that is the problem. 
>
> And allowing direct commands is the solution.
>
> Just to dump the text output of gdb, it doesn't need to know the command
>>
>> yep hit "c" instead of "x" (on most keyboards they are next to each 
>> other) 
> continue, step, next, stepi, nexti, stop, kill, quit
>
> Those might not be all commands that are dangerous, but I doubt a 
> novice will know the names of another ones.
> And Lazarus can check for them and their abbreviations and call the 
> corresponding interface function.
>
>> And Apple supplies are broken gdb. Some of those commands can do harm. 
> That's Apple's problem
>
>>
>> Feel free to provide it as an installable package. 
> Can a plugin even send commands to the debugger, if that define is not 
> set?
>
> 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
>> 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
>
> On 06/01/12 19:40, Martin wrote:
>> On 01/06/2012 18:30, Benito van der Zander wrote:
>>> Hi,
>>>>
>>>> Have you tried to compile the IDE with DBG_WITH_DEBUGGER_DEBUG
>>>>  defined?
>>>>
>>>> It does exactly the above. It has been there a very long time.
>>>>
>>>> It has also been decided, that this feature will only be available 
>>>> via this define.
>>>>
>>> I think it would be much better, if it were a regular feature like 
>>> in Ludo's patch:
>>>
>>> * the define is difficult to find
>> That is because it is not supposed to be used.
>>
>> Yes for the experienced users there are sometimes cases that would 
>> make it desire-able. For the novice it would be in the best case 
>> something they do not use. But it could easily cause them problems.
>>
>> I already pointed out, how easy you can upset the IDE-to-gdb 
>> interface, if you issue the wrong command.
>>
>>
>>>
>>> * if you recompile Lazarus frequently, it often disappears.
>> I recompile very frequently, and it never wet.
>> I always recompile from the Tools menu
>>
>>>
>>> * if you have a Lazarus without define, you can't enable it without 
>>> recompiling and stopping the debugged application
>>>
>>> * Lazarus will never have direct support for all possible gdb 
>>> commands. If you have added them all, there will be new ones in gdb
>> And that is the problem.
>>
>> This also means that if gdb access is possible, then it is impossible 
>> (even if attempted) for the IDE to monitor all the commands.
>> Given that some commands have hidden features...
>> If added people will accidentally type the wrong command.
>>
>>>
>>> * The output in the debug window is difficult to read
>> Yes.
>>
>> That window shouldn't even exist. Or move to IDE internals
>> It is only useful, so people can sent the centent, if something went 
>> wrong
>>
>>>
>>> * Most commands people use won't break the debugging session, like 
>>> info, x, ...
>> yep hit "c" instead of "x" (on most keyboards they are next to each 
>> other)
>>
>> And Apple supplies are broken gdb. Some of those commands can do harm.
>>
>>>
>>>   (and I just debugged an application that crashes if debugged and 
>>> "set scheduler-locking on" is not set, with such a patch this
>>>    option could be set, without restarting gdb)
>>>
>>> * If debug commands were that dangerous, Lazarus could show a 
>>> warning, when the feature is used the first time.
>>>
>>> * You can write your own gdb python plugins and call them
>>>
>>> * People using a programming language are not stupid and can figure 
>>> out how to use gdb
>>
>> Feel free to provide it as an installable package.
>>
>> Then it can be downloaded and installed
>>
>> -- 
>> _______________________________________________
>> Lazarus mailing list
>> Lazarus at lists.lazarus.freepascal.org
>> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>
> -- 
> _______________________________________________
> Lazarus mailing list
> Lazarus at lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus