forked from Imagelibrary/binutils-gdb
e2f620135d
This commit makes two changes to how we match newline characters in the gdb_test proc. First, for the newline pattern between the command output and the prompt, I propose changing from '[\r\n]+' to an explicit '\r\n'. The old pattern would spot multiple newlines, and so there are a few places where, as part of this commit, I've needed to add an extra trailing '\r\n' to the pattern in the main test file, where GDB's output actually includes a blank line. But I think this is a good thing. If a command produces a blank line then we should be checking for it, the current gdb_test doesn't do that. But also, with the current gdb_test, if a blank line suddenly appears in the output, this is going to be silently ignored, and I think this is wrong, the test should fail in that case. Additionally, the existing pattern will happily match a partial newline. There are a strangely large number of tests that end with a random '.' character. Not matching a literal period, but matching any single character, this is then matching half of the trailing newline sequence, while the \[\r\n\]+ in gdb_test is matching the other half of the sequence. I can think of no reason why this would be intentional, I suspect that the expected output at one time included a period, which has since been remove, but I haven't bothered to check on this. In this commit I've removed all these unneeded trailing '.' characters. The basic rule of gdb_test after this is that the expected pattern needs to match everything up to, but not including the newline sequence immediately before the GDB prompt. This is generally how the proc is used anyway, so in almost all cases, this commit represents no significant change. Second, while I was cleaning up newline matching in gdb_test, I've also removed the '[\r\n]*' that was added to the start of the pattern passed to gdb_test_multiple. The addition of this pattern adds no value. If the user pattern matches at the start of a line then this would match against the newline sequence. But, due to the '*', if the user pattern doesn't match at the start of a line then this group doesn't care, it'll happily match nothing. As such, there's no value to it, it just adds more complexity for no gain, so I'm removing it. No tests will need updating as a consequence of this part of the patch. Reviewed-By: Tom Tromey <tom@tromey.com>
136 lines
4.4 KiB
Plaintext
136 lines
4.4 KiB
Plaintext
# Tests of overloaded operators resolution.
|
|
# Copyright 1998-2023 Free Software Foundation, Inc.
|
|
|
|
# This program is free software; you can redistribute it and/or modify
|
|
# it under the terms of the GNU General Public License as published by
|
|
# the Free Software Foundation; either version 3 of the License, or
|
|
# (at your option) any later version.
|
|
#
|
|
# This program is distributed in the hope that it will be useful,
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
# GNU General Public License for more details.
|
|
#
|
|
# You should have received a copy of the GNU General Public License
|
|
# along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
# written by Elena Zannoni (ezannoni@cygnus.com)
|
|
#
|
|
# source file "userdef.cc"
|
|
#
|
|
|
|
require allow_stl_tests
|
|
|
|
standard_testfile .cc
|
|
|
|
if {[prepare_for_testing "failed to prepare" $testfile $srcfile {debug c++}]} {
|
|
return -1
|
|
}
|
|
|
|
if {![runto_main]} {
|
|
return
|
|
}
|
|
|
|
gdb_test "break marker1" \
|
|
"Breakpoint .*${srcfile}.*"
|
|
|
|
gdb_test "cont" \
|
|
"Break.* marker1(\\(\\)|) \\(\\) at .*:$decimal.*" \
|
|
"continue to marker1"
|
|
|
|
gdb_test "up" " in main .*" "up from marker1"
|
|
|
|
gdb_test "print one + two" "\\\$\[0-9\]* = {x = 6, y = 8}"
|
|
|
|
# If GDB fails to restore the selected frame properly after the
|
|
# inferior function call above (see GDB PR 1155 for an explanation of
|
|
# why this might happen), all the subsequent tests will fail. We
|
|
# should detect report that failure, but let the marker call finish so
|
|
# that the rest of the tests can run undisturbed.
|
|
gdb_test_multiple "frame" "re-selected 'main' frame after inferior call" {
|
|
-re "#0 marker1.*$gdb_prompt $" {
|
|
setup_kfail "gdb/1155" s390-*-linux-gnu
|
|
fail "re-selected 'main' frame after inferior call"
|
|
gdb_test "finish" ".*main.*at .*userdef.cc:.*// marker1-returns-here.*" \
|
|
"finish call to marker1"
|
|
}
|
|
-re "#1 ($hex in )?main.*$gdb_prompt $" {
|
|
pass "re-selected 'main' frame after inferior call"
|
|
}
|
|
}
|
|
|
|
gdb_test "print one - two" "\\\$\[0-9\]* = {x = -2, y = -2}"
|
|
|
|
gdb_test "print one * two" "\\\$\[0-9\]* = {x = 8, y = 15}"
|
|
|
|
gdb_test "print one / two" "\\\$\[0-9\]* = {x = 0, y = 0}"
|
|
|
|
gdb_test "print one % two" "\\\$\[0-9\]* = {x = 2, y = 3}"
|
|
|
|
gdb_test "print one && two" "\\\$\[0-9\]* = 1"
|
|
|
|
gdb_test "print one || two" "\\\$\[0-9\]* = 1"
|
|
|
|
gdb_test "print one & two" "\\\$\[0-9\]* = {x = 0, y = 1}"
|
|
|
|
gdb_test "print one | two" "\\\$\[0-9\]* = {x = 6, y = 7}"
|
|
|
|
gdb_test "print one ^ two" "\\\$\[0-9\]* = {x = 6, y = 6}"
|
|
|
|
gdb_test "print one < two" "\\\$\[0-9\]* = 1"
|
|
|
|
gdb_test "print one <= two" "\\\$\[0-9\]* = 1"
|
|
|
|
gdb_test "print one > two" "\\\$\[0-9\]* = 0"
|
|
|
|
gdb_test "print one >= two" "\\\$\[0-9\]* = 0"
|
|
|
|
gdb_test "print one == two" "\\\$\[0-9\]* = 0"
|
|
gdb_test "print one.operator== (two)" "\\\$\[0-9\]* = 0"
|
|
|
|
gdb_test "print one != two" "\\\$\[0-9\]* = 1"
|
|
|
|
# Can't really check the output of this one without knowing
|
|
# target integer width. Make sure we don't try to call
|
|
# the iostreams operator instead, though.
|
|
gdb_test "print one << 31" "\\\$\[0-9\]* = {x = -?\[0-9\]*, y = -?\[0-9\]*}"
|
|
|
|
# Should be fine even on < 32-bit targets.
|
|
gdb_test "print one >> 31" "\\\$\[0-9\]* = {x = 0, y = 0}"
|
|
|
|
gdb_test "print !one" "\\\$\[0-9\]* = 0"
|
|
|
|
# Assumes 2's complement. So does everything...
|
|
gdb_test "print +one" "\\\$\[0-9\]* = {x = 2, y = 3}"
|
|
|
|
gdb_test "print ~one" "\\\$\[0-9\]* = {x = -3, y = -4}"
|
|
|
|
gdb_test "print -one" "\\\$\[0-9\]* = {x = -2, y = -3}"
|
|
|
|
gdb_test "print one++" "\\\$\[0-9\]* = {x = 2, y = 4}"
|
|
|
|
gdb_test "print ++one" "\\\$\[0-9\]* = {x = 3, y = 4}"
|
|
|
|
gdb_test "print one--" "\\\$\[0-9\]* = {x = 3, y = 3}"
|
|
|
|
gdb_test "print --one" "\\\$\[0-9\]* = {x = 2, y = 3}"
|
|
|
|
gdb_test "print one += 7" "\\\$\[0-9\]* = {x = 9, y = 10}"
|
|
|
|
gdb_test "print two = one" "\\\$\[0-9\]* = {x = 9, y = 10}"
|
|
|
|
# Check that GDB tolerates whitespace in operator names.
|
|
gdb_test "break A2::operator+" ".*Breakpoint $decimal at.*"
|
|
gdb_test "break A2::operator +" ".*Breakpoint $decimal at.*"
|
|
|
|
# Check that GDB handles operator* correctly.
|
|
gdb_test "print c" "\\\$\[0-9\]* = {m = {z = .*}}"
|
|
gdb_test "print *c" "\\\$\[0-9\]* = \\(Member &\\) @$hex: {z = .*}"
|
|
gdb_test "print &*c" "\\\$\[0-9\]* = \\(Member \\*\\) $hex"
|
|
gdb_test "ptype &*c" "type = (struct|class) Member {(\[\r\n \]+public:)?\[\r\n \]+int z;\[\r\n\].*} \\*"
|
|
|
|
gdb_test "print operator== (mem1, mem2)" " = false"
|
|
gdb_test "print operator== (mem1, mem1)" " = true"
|
|
|
|
gdb_exit
|