[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-debug-dev] 1.0.1 Breakpoint Conditions and GDB 5.2.1 MI
|
>
>
> Hi!
>
> We have found issues with breakpoint conditions on 1.0.1 and gdb 5.2.1. The
> meat of the problem is that if a user types j==20 into the condition
> window, CDT sends the command -break-condition X "j==20" to gdb. On our
> version of 5.2.1, this causes GDB to allocate space for the string "j==20"
> and then use the pointer to that string as the evaluation, which always
> returns true.
>
> We are a little stumped here. Do you all feel that this is a GDB/MI problem
> or is this something in the CDT? Are the quotes legal? Our instinct says
> that what CDT is sending is valid and GDB is buggy. Here's why:
>
> Consider the break condition: strcmp(" ",foo).
>
> This is a valid GDB condition, but the space in the first argument to
> strcmp requires the mi argument be quoted, the only way to send this to mi is:
>
> -break-condition 1 "strcmp(\" \",foo)"
>
> That implies that MI should be stripping unquoted ""'s around the argument.
> We would think that if you really wanted the behavior that GDB is
> demonstrating for this you should send: -break-command 1 \"j==20\". Perhaps
> we are off base. Any thoughts?
Yes, agreed.
>
In this case 'j==20', I'm suprise to see "".
The code will only put surrounding "" if the argument contains space.
So in your example 'j==20', should not be any surrounding quotes.
See MICommand.toString().
This is a bug in GDB, I've already raise the issue/PR in GDB/MI bugzilla/GNATS.
Each command in gdb/MI is doing its own argument/parameter parsing.
Some will accept "--" as separator of options vs arguments, others
will not etc ... very inconsistent. All the gdb(GDB/MI) commands should
use the same consistent argument parsing code, I could not find
the PR in GDB/MI GNATS db ..
