Re: [Lazarus] Conditional Debugger breakpoints not working ?
On 20/02/2023 15:14, Michael Van Canneyt via lazarus wrote: On Mon, 20 Feb 2023, Martin Frb via lazarus wrote: It is a problem on Mac, with LLDB. Though I am not even sure that conditional breakpoint are supported at all... Just checked, conditions are set. But users must type them C-style. That is "a == 1". They are: https://stackoverflow.com/questions/37204551/lldb-setting-conditional-breakpoint-with-string-equality-as-condition That looks like it actually invokes strcmp() in the debugged exe. Which then depends on an fpc generated app having that function, and having sufficient debug info to have it found. The GDB $_streq on the other hand is an gdb intrinsic. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Conditional Debugger breakpoints not working ?
On Mon, 20 Feb 2023, Martin Frb via lazarus wrote: On 20/02/2023 13:46, Michael Van Canneyt via lazarus wrote: I suggest you adapt the wiki to clarify all this. While you're at it, The link in the wiki page to the gdb convenience functions is broken. updated In general, I don't think you can expect the user to know that he should use $_streq(myvar, "hello"), specially the cmem condition that seems necessary. Ideally, the IDE could detect a string and transform the expression. This always has been the issue with gdb. If you had a watch with anything but just a plain variable name, then gdb may give you: - an error, - or an incorrect result, - or the correct result For watches, there is quite a lot of code in the IDE to try and fix those things. There are testcases, that can be run with different debug-info, and diff gdb versions. (And they run for many hours / and unfortunately still have some errors, some false errors...). But there is no way to get to 100%. In many cases gdb simple does not give enough info to detect the necessary information on the underlaying type. (And when trying to get this, one has to be carefully not to crash gdb). Also it makes evaluating each individual watch a lot slower (at least factor 3 or 4). Though on that I have always pushed the point that a "correct result" is worth *any* wait time. Yes. An incorrect result may result in infinite wait time :-) In any case, with conditional breakpoints it would be even more complex It would be nice to have, but with the availability of FpDebug, it is very unlikely that will be fixed. (There are simply a lot of other things that (should) have more priority) I may add a warning to the breakpoint dlg, that for non-fpdebug will display a red TLabel below the input, with some text that the condition may not work at all. I think this is a good idea. It is a problem on Mac, with LLDB. Though I am not even sure that conditional breakpoint are supported at all... They are: https://stackoverflow.com/questions/37204551/lldb-setting-conditional-breakpoint-with-string-equality-as-condition LLDB probably can do them (with restrictions like gdb). But the IDE has absolutely on code to translate "pascal to lldb" => because for watches it can evaluate with fpdebug. But conditional breakpoints must be done by lldb, or they become very very slow. (That is if they need to pass lots of time before they match the condition, and each hit pass 1 second or more, you quickly get to several minutes of wait time) No problem. I realize it is not easy to solve generally, although a solution for 'simple' strings would be welcome. I'll stick to poor man's conditionals. Then the compiler will tell me what I do wrong :) Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Conditional Debugger breakpoints not working ?
On 20/02/2023 13:46, Michael Van Canneyt via lazarus wrote: I suggest you adapt the wiki to clarify all this. While you're at it, The link in the wiki page to the gdb convenience functions is broken. updated In general, I don't think you can expect the user to know that he should use $_streq(myvar, "hello"), specially the cmem condition that seems necessary. Ideally, the IDE could detect a string and transform the expression. This always has been the issue with gdb. If you had a watch with anything but just a plain variable name, then gdb may give you: - an error, - or an incorrect result, - or the correct result For watches, there is quite a lot of code in the IDE to try and fix those things. There are testcases, that can be run with different debug-info, and diff gdb versions. (And they run for many hours / and unfortunately still have some errors, some false errors...). But there is no way to get to 100%. In many cases gdb simple does not give enough info to detect the necessary information on the underlaying type. (And when trying to get this, one has to be carefully not to crash gdb). Also it makes evaluating each individual watch a lot slower (at least factor 3 or 4). Though on that I have always pushed the point that a "correct result" is worth *any* wait time. In any case, with conditional breakpoints it would be even more complex It would be nice to have, but with the availability of FpDebug, it is very unlikely that will be fixed. (There are simply a lot of other things that (should) have more priority) I may add a warning to the breakpoint dlg, that for non-fpdebug will display a red TLabel below the input, with some text that the condition may not work at all. It is a problem on Mac, with LLDB. Though I am not even sure that conditional breakpoint are supported at all... LLDB probably can do them (with restrictions like gdb). But the IDE has absolutely on code to translate "pascal to lldb" => because for watches it can evaluate with fpdebug. But conditional breakpoints must be done by lldb, or they become very very slow. (That is if they need to pass lots of time before they match the condition, and each hit pass 1 second or more, you quickly get to several minutes of wait time) -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Conditional Debugger breakpoints not working ?
On Mon, 20 Feb 2023, Martin Frb via lazarus wrote: On 20/02/2023 12:31, Michael Van Canneyt via lazarus wrote: I'm trying to set a condition on a breakpoint. I have a local variable aUnit, type string: var aUnit : string; I wish the breakpoint is only triggered when aUnit equals 'termio'. So, in the breakpoint properties dialog, I enter the condition: aUnit='termio' It seems to have no effect whatsoever. The breakpoint is triggered always at the first traversal of the line. I tried variations (uppercase, lowercase) , but to no avail. Looking at the debug internals window, I see that the expression is only (correctly) evaluated by gdb when I move the mouse over the identifier in the sources: (gdb) gdb doesn't know pascal strings, or how do an "=" operation on them. You can try to get $_streq(myvar, "hello") to work https://sourceware.org/gdb/onlinedocs/gdb/Convenience-Funs.html Or use FpDebug. FpDebug can compare strings. I suggest you adapt the wiki to clarify all this. While you're at it, The link in the wiki page to the gdb convenience functions is broken. In general, I don't think you can expect the user to know that he should use $_streq(myvar, "hello"), specially the cmem condition that seems necessary. Ideally, the IDE could detect a string and transform the expression. Michael.-- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Conditional Debugger breakpoints not working ?
On 20/02/2023 12:31, Michael Van Canneyt via lazarus wrote: I'm trying to set a condition on a breakpoint. I have a local variable aUnit, type string: var aUnit : string; I wish the breakpoint is only triggered when aUnit equals 'termio'. So, in the breakpoint properties dialog, I enter the condition: aUnit='termio' It seems to have no effect whatsoever. The breakpoint is triggered always at the first traversal of the line. I tried variations (uppercase, lowercase) , but to no avail. Looking at the debug internals window, I see that the expression is only (correctly) evaluated by gdb when I move the mouse over the identifier in the sources: (gdb) gdb doesn't know pascal strings, or how do an "=" operation on them. You can try to get $_streq(myvar, "hello") to work https://sourceware.org/gdb/onlinedocs/gdb/Convenience-Funs.html Or use FpDebug. FpDebug can compare strings. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Conditional Debugger breakpoints not working ?
Hi,
I'm trying to set a condition on a breakpoint.
I have a local variable aUnit, type string:
var
aUnit : string;
I wish the breakpoint is only triggered when aUnit equals 'termio'.
So, in the breakpoint properties dialog, I enter the condition:
aUnit='termio'
It seems to have no effect whatsoever. The breakpoint is triggered always at
the first traversal of the line.
I tried variations (uppercase, lowercase) , but to no avail.
Looking at the debug internals window, I see that the expression is
only (correctly) evaluated by gdb when I move the mouse over the identifier
in the sources:
(gdb)
&"ptype AUNIT\n"
~"type = ^Char\n"
^done
(gdb)
&"ptype AUNIT^\n"
~"type = Char\n"
^done
(gdb)
&"whatis AUNIT\n"
~"type = ANSISTRING\n"
^done
(gdb)
<-data-evaluate-expression AUNIT>
^done,value="0x77f73b18 'si_prc'"
(gdb)
So it can correctly evaluate the value aUnit.
The question is, why is it ignoring my condition ?
After some digging in the gdb output I find this:
&"Error in testing breakpoint condition:\n"
&"evaluation of this expression requires the program to have a function
\"malloc\".\n"
Hm. No mention of this in:
https://wiki.lazarus.freepascal.org/Debugger_Setup
https://wiki.lazarus.freepascal.org/IDE_Window:_Breakpoints#Breakpoint_properties
OK, File under 'undocumented' and ignore for the time being, but I add cmem unit
to my program.
Seemingly, gdb now accepts the breakpoint condition:
<-break-insert "\"/home/michael/domakefile.lpr\":161">
^done,bkpt={number="7",type="breakpoint",disp="keep",enabled="y",addr="0x00401fe7",func="ADDRECIPE",file="domakefile.lpr",fullname="/home/michael/domakefile.lpr",line="161",thread-groups=["i1"],times="0",original-location="/home/michael/domakefile.lpr:161"}
(gdb)
<-break-condition 7 AUNIT="termio">
^done
(gdb)
<-break-enable 7>
^done
That makes it even worse: the breakpoint is simply never observed.
If I do a poor man's conditional breakpoint:
if (aUnit='termio') then
Writeln('Aloha'); <-- set breakpoint on this line
and run, I see that unit 'termio' is definitely encountered.
So, "Houston, we have a problem..."
Suggestions, things I maybe forgot ?
Michael.
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
