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>
&"ptype AUNIT\n"
~"type = ^Char\n"
^done
(gdb)
<ptype AUNIT^>
&"ptype AUNIT^\n"
~"type = Char\n"
^done
(gdb)
<whatis AUNIT>
&"whatis AUNIT\n"
~"type = ANSISTRING\n"
^done
(gdb)
<-data-evaluate-expression AUNIT>
^done,value="0x7ffff7f73b18 '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="0x0000000000401fe7",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.

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.

updated

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 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)

Yes. An incorrect result may result in infinite wait time :-)

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

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.

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.