diff options
author | Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> | 2021-07-26 08:25:03 +0200 |
---|---|---|
committer | Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> | 2021-07-26 08:46:02 +0200 |
commit | b6c4205149824bfc3e5ab9e12819dcc0fc2af29d (patch) | |
tree | 62da7978ba7ce96065827a9c07095dbc1049ca70 /gdb/testsuite/ChangeLog | |
parent | b924d9bad57a1ddb2e0f83229db5a33b5fb7bec6 (diff) | |
download | gdb-b6c4205149824bfc3e5ab9e12819dcc0fc2af29d.zip gdb-b6c4205149824bfc3e5ab9e12819dcc0fc2af29d.tar.gz gdb-b6c4205149824bfc3e5ab9e12819dcc0fc2af29d.tar.bz2 |
gdb/mi: handle no condition argument case for -break-condition
As reported in PR gdb/28076 [1], passing no condition argument to the
-break-condition command (e.g.: "-break-condition 2") should clear the
condition for breakpoint 2, just like CLI's "condition 2", but instead
an error message is returned:
^error,msg="-break-condition: Missing the <number> and/or <expr> argument"
The current implementation of the -break-condition command's argument
handling (79aabb7308c "gdb/mi: add a '--force' flag to the
'-break-condition' command") was done according to the documentation,
where the condition argument seemed mandatory. However, the
-break-condition command originally (i.e. before the 79aabb7308c
patch) used the CLI's "cond" command, and back then not passing a
condition argument was clearing out the condition. So, this is a
regression in terms of the behavior.
Fix the argument handling of the -break-condition command to allow not
having a condition argument, and also update the document to make the
behavior clear. Also add test cases to test the scenarios which were
previously not covered.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=28076
Diffstat (limited to 'gdb/testsuite/ChangeLog')
0 files changed, 0 insertions, 0 deletions