aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/lib/gdb-python.exp
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2022-06-08 14:04:36 +0100
committerAndrew Burgess <aburgess@redhat.com>2022-06-09 14:40:48 +0100
commit0e471fde0742bbbc8e34f0d082d1b35c19aee96f (patch)
tree4363dd29eb1c96ebf5832e42c1ee6f0258fd5f3b /gdb/testsuite/lib/gdb-python.exp
parent08b326ee0a6384508703f9187905bb00bfe3d5d9 (diff)
downloadgdb-0e471fde0742bbbc8e34f0d082d1b35c19aee96f.zip
gdb-0e471fde0742bbbc8e34f0d082d1b35c19aee96f.tar.gz
gdb-0e471fde0742bbbc8e34f0d082d1b35c19aee96f.tar.bz2
gdb/testsuite: handle errors better in test_compiler_info
Now that get_compiler_info might actually fail (if the language is not handled), then we should try to handle this failure better in test_compiler_info. After this commit, if get_compiler_info fails then we will return a suitable result depending on how the user called test_compiler_info. If the user does something like: set version [test_compiler_info "" "unknown-language"] Then test_compiler_info will return an empty string. My assumption is that the user will be trying to match 'version' against something, and the empty string hopefully will not match. If the user does something like: if { [test_compiler_info "some_pattern" "unknown-language"] } { .... } Then test_compiler_info will return false which seems the obvious choice. There should be no change in the test results after this commit.
Diffstat (limited to 'gdb/testsuite/lib/gdb-python.exp')
0 files changed, 0 insertions, 0 deletions