aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite
diff options
context:
space:
mode:
authorGuinevere Larsen <guinevere@redhat.com>2024-08-02 08:46:28 -0300
committerGuinevere Larsen <guinevere@redhat.com>2024-09-20 16:08:23 -0300
commitb0170acd5a9e834e2b37ff151fa817e9a7a1412a (patch)
tree32f2046417fa67c01d8d4fde37265e009364aaee /gdb/testsuite
parentc588e374965509b81a623ce9ef79a026f27d2592 (diff)
downloadgdb-b0170acd5a9e834e2b37ff151fa817e9a7a1412a.zip
gdb-b0170acd5a9e834e2b37ff151fa817e9a7a1412a.tar.gz
gdb-b0170acd5a9e834e2b37ff151fa817e9a7a1412a.tar.bz2
gdb/testsuite: rework bp-cond-failure to not depend on inlining
The test gdb.base/bp-cond-failure is implicitly expecting that the function foo will be inlined twice and gdb will be able to find 2 locations to place a breakpoint. When clang is used, gdb only finds one location which causes the test to fail. Since the test is not worried about handling breakpoints on inlined functions, but rather on the format of the message on a breakpoint condition fail, this seems like a false fail report. This commit reworks the test to be in c++, and uses function overloading to ensure that 2 locations will always be found. Empirical testing showed that, for clang, we will land on location 2 with the currest exp commands, no matter the order of the functions declared, whereas for gcc it depends on the order that functions were declared, so they are ordered to always land on the second location, this way we are able to hardcode it and check for it. Reviewed-by: Keith Seitz <keiths@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
Diffstat (limited to 'gdb/testsuite')
-rw-r--r--gdb/testsuite/gdb.base/bp-cond-failure.c14
-rw-r--r--gdb/testsuite/gdb.base/bp-cond-failure.exp46
2 files changed, 40 insertions, 20 deletions
diff --git a/gdb/testsuite/gdb.base/bp-cond-failure.c b/gdb/testsuite/gdb.base/bp-cond-failure.c
index ffab098..b742139 100644
--- a/gdb/testsuite/gdb.base/bp-cond-failure.c
+++ b/gdb/testsuite/gdb.base/bp-cond-failure.c
@@ -15,8 +15,14 @@
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>. */
-static inline int __attribute__((__always_inline__))
-foo ()
+static int
+foo (int x)
+{
+ return 0;
+}
+
+static int
+foo (char c)
{
return 0; /* Multi-location breakpoint here. */
}
@@ -24,7 +30,7 @@ foo ()
static int __attribute__((noinline))
bar ()
{
- int res = foo (); /* Single-location breakpoint here. */
+ int res = foo ('1'); /* Single-location breakpoint here. */
return res;
}
@@ -34,7 +40,7 @@ main ()
{
int res = bar ();
- res = foo ();
+ res = foo (1);
return res;
}
diff --git a/gdb/testsuite/gdb.base/bp-cond-failure.exp b/gdb/testsuite/gdb.base/bp-cond-failure.exp
index a82cedd..b4c046c 100644
--- a/gdb/testsuite/gdb.base/bp-cond-failure.exp
+++ b/gdb/testsuite/gdb.base/bp-cond-failure.exp
@@ -27,7 +27,7 @@
standard_testfile
if { [prepare_for_testing "failed to prepare" ${binfile} "${srcfile}" \
- {debug}] == -1 } {
+ {debug c++}] == -1 } {
return
}
@@ -44,7 +44,7 @@ if { [is_address_zero_readable] } {
return
}
-proc run_test { cond_eval access_type lineno nloc } {
+proc run_test { cond_eval access_type bpexpr nloc } {
clean_restart ${::binfile}
if { ![runto_main] } {
@@ -56,23 +56,37 @@ proc run_test { cond_eval access_type lineno nloc } {
}
# Setup the conditional breakpoint and record its number.
- gdb_breakpoint "${::srcfile}:${lineno} if (*(${access_type} *) 0) == 0"
+ gdb_breakpoint "${bpexpr} if (*(${access_type} *) 0) == 0"
+
+ # This test aims to test that GDB displays the correct breakpoint number
+ # and location when there is an error testing a breakpoint condition,
+ # so it is important to hardcode the breakpoint number into the regex,
+ # along with the location, if applicable.
set bp_num [get_integer_valueof "\$bpnum" "*UNKNOWN*"]
if { $nloc > 1 } {
- set bp_num_pattern "${bp_num}.1"
+ # We hardcode location 2 because, for some reason, Clang will always
+ # order the debug information so we hit the second location. For
+ # simplicity the .c is ordered in such a way that GCC will also order
+ # the debug info to have us land on location 2.
+ gdb_test "continue" \
+ [multi_line \
+ "Continuing\\." \
+ "Error in testing condition for breakpoint ${bp_num}.2:" \
+ "Cannot access memory at address 0x0" \
+ "" \
+ "Breakpoint ${bp_num}.2, foo \\(c=49 ...\\) at \[^\r\n\]+:\[0-9\]+" \
+ "${::decimal}\\s+\[^\r\n\]+ breakpoint here\\. \[^\r\n\]+"]
} else {
- set bp_num_pattern "${bp_num}"
+ gdb_test "continue" \
+ [multi_line \
+ "Continuing\\." \
+ "Error in testing condition for breakpoint ${bp_num}:" \
+ "Cannot access memory at address 0x0" \
+ "" \
+ "Breakpoint ${bp_num}, bar \\(\\) at \[^\r\n\]+:\[0-9\]+" \
+ "${::decimal}\\s+\[^\r\n\]+ breakpoint here\\. \[^\r\n\]+"]
}
-
- gdb_test "continue" \
- [multi_line \
- "Continuing\\." \
- "Error in testing condition for breakpoint ${bp_num_pattern}:" \
- "Cannot access memory at address 0x0" \
- "" \
- "Breakpoint ${bp_num_pattern}, \(foo\|bar\) \\(\\) at \[^\r\n\]+:${lineno}" \
- "${::decimal}\\s+\[^\r\n\]+ breakpoint here\\. \[^\r\n\]+"]
}
# If we're using a remote target then conditions could be evaulated
@@ -101,7 +115,7 @@ gdb_test_multiple "show breakpoint condition-evaluation" "" {
}
# Where the breakpoint will be placed.
-set bp_line_multi_loc [gdb_get_line_number "Multi-location breakpoint here"]
+set bp_line_multi_loc "foo"
set bp_line_single_loc [gdb_get_line_number "Single-location breakpoint here"]
foreach_with_prefix access_type { "char" "short" "int" "long long" } {
@@ -110,7 +124,7 @@ foreach_with_prefix access_type { "char" "short" "int" "long long" } {
run_test $cond_eval $access_type $bp_line_multi_loc 2
}
with_test_prefix "single-loc" {
- run_test $cond_eval $access_type $bp_line_single_loc 1
+ run_test $cond_eval $access_type "${srcfile}:${bp_line_single_loc}" 1
}
}
}