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