While working on earlier patches, I noticed that the DAP C++ exception
test had some strange results in the log. Digging into this, I found
that while the Ada catchpoints emit a "bkptno" field in the MI result,
the C++ ones do not -- but the DAP code was relying on this.
This patch fixes the problem by changing which field is examined, and
then updates the tests to verify this.
Reviewed-by: Keith Seitz <keiths@redhat.com>
else:
raise DAPException("Invalid exception filterID: " + str(filterId))
result = exec_mi_and_log(cmd)
+ # While the Ada catchpoints emit a "bkptno" field here, the C++
+ # ones do not. So, instead we look at the "number" field.
+ num = result["bkpt"]["number"]
# A little lame that there's no more direct way.
for bp in gdb.breakpoints():
- if bp.number == result["bkptno"]:
+ if bp.number == num:
return bp
# Not a DAPException because this is definitely unexpected.
raise Exception("Could not find catchpoint after creating")
gdb_assert {[dict get $spec source path] != "null"} \
"breakpoint $i path"
}
+
+ # Breakpoint should be unverified and pending.
+ gdb_assert {[dict get $spec verified] == "false"} \
+ "catchpoint $i is unverified"
+ gdb_assert {[dict get $spec reason] == "pending"} \
+ "catchpoint $i is pending"
}
incr i
}
# breakpoints.
gdb_assert {[llength $bps] == 3} "three breakpoints"
+# Each breakpoint should be unverified and pending.
+foreach bp $bps {
+ with_test_prefix [dict get $bp id] {
+ gdb_assert {[dict get $bp verified] == "false"} \
+ "catchpoint is unverified"
+ gdb_assert {[dict get $bp reason] == "pending"} \
+ "catchpoint is pending"
+ }
+}
+
dap_check_request_and_response "configurationDone" configurationDone
if {[dap_launch $testfile] == ""} {