Clean up gdb.gdb/selftest.exp
Commit Message
I recently see the test fails like this,
(gdb) PASS: gdb.gdb/selftest.exp: step over argv initialization
list^M
487 std::vector<struct cmdarg> cmdarg_vec;^M
(gdb) FAIL: gdb.gdb/selftest.exp: unknown source line (after step over argv initialization)
step^M
std::vector<cmdarg, std::allocator<cmdarg> >::vector (this=0x7fffffffdc10) at ../../binutils-gdb/gdb/main.c:487^M
487 std::vector<struct cmdarg> cmdarg_vec;^M
(gdb) FAIL: gdb.gdb/selftest.exp: step into xmalloc call
These fails are caused by using std::vector in commit
f60ee22ea1d62f7004511ec65a3ad76890032d88. selttest.exp should match
the source code of GDB. This patch adds some new regexp to match
code using std::vector, and also removes some out of date regexp.
proc "do_steps_and_nexts left us ready to execute an xmalloc call",
however, there is no xmalloc called, so I also remove these bits.
I am also wondering the value of do_steps_and_nexts, can we just
remove it completely?
It fixed fails on x86_64-linux and aarch64-linux.
gdb/testsuite:
2016-12-14 Yao Qi <yao.qi@linaro.org>
* gdb.gdb/selftest.exp (do_steps_and_nexts): Add regexp to
match new code, and remove some out of date regexp.
Remove test about stepping into xmalloc.
---
gdb/testsuite/gdb.gdb/selftest.exp | 93 +++++---------------------------------
1 file changed, 11 insertions(+), 82 deletions(-)
Comments
On 12/14/2016 02:19 PM, Yao Qi wrote:
> I recently see the test fails like this,
>
> (gdb) PASS: gdb.gdb/selftest.exp: step over argv initialization
> list^M
> 487 std::vector<struct cmdarg> cmdarg_vec;^M
> (gdb) FAIL: gdb.gdb/selftest.exp: unknown source line (after step over argv initialization)
>
> step^M
> std::vector<cmdarg, std::allocator<cmdarg> >::vector (this=0x7fffffffdc10) at ../../binutils-gdb/gdb/main.c:487^M
> 487 std::vector<struct cmdarg> cmdarg_vec;^M
> (gdb) FAIL: gdb.gdb/selftest.exp: step into xmalloc call
>
> These fails are caused by using std::vector in commit
> f60ee22ea1d62f7004511ec65a3ad76890032d88. selttest.exp should match
> the source code of GDB. This patch adds some new regexp to match
> code using std::vector, and also removes some out of date regexp.
>
> proc "do_steps_and_nexts left us ready to execute an xmalloc call",
> however, there is no xmalloc called, so I also remove these bits.
>
> I am also wondering the value of do_steps_and_nexts, can we just
> remove it completely?
Yeah, I don't see much value either. It's a constant source of
update pain.
I've found the bits of selftest.exp that interact with SIGINT
useful in the past, as that interacts with readline's SIGINT
handler. IIUC, that caught a bug in some local version of my
console work earlier in the year. So I'd prefer to keep those
bits. But I wouldn't miss do_steps_and_nexts for sure.
Thanks,
Pedro Alves
@@ -83,12 +83,12 @@ proc do_steps_and_nexts {} {
set description "step over ttyarg initialization"
set command "step"
}
- -re ".*cmdarg_vec = NULL.*$gdb_prompt $" {
- set description "step over cmdarg_vec initialization"
- set command "step"
+ -re ".*std::vector<struct cmdarg> cmdarg_vec.*$gdb_prompt $" {
+ set description "next over cmdarg_vec initialization"
+ set command "next"
}
- -re ".*pre_stat_chain = make_command_stats_cleanup.*$gdb_prompt $" {
- set description "next over make_command_stats_cleanup and everything it calls"
+ -re ".*std::vector<char \\*> dirarg.*$gdb_prompt $" {
+ set description "next over dirarg initialization"
set command "next"
}
-re ".*START_PROGRESS.*$gdb_prompt $" {
@@ -98,10 +98,6 @@ proc do_steps_and_nexts {} {
set description "next over START_PROGRESS and everything it calls"
set command "next"
}
- -re ".*mac_init.*$gdb_prompt $" {
- set description "next over mac_init and everything it calls"
- set command "next"
- }
-re ".*init_malloc.*$gdb_prompt $" {
# gdb 6.2.X is the last gdb which called init_malloc
set description "next over init_malloc and everything it calls"
@@ -111,6 +107,10 @@ proc do_steps_and_nexts {} {
set description "next over lim_at_start initialization"
set command "next"
}
+ -re ".*scoped_command_stats stat_reporter .*$gdb_prompt $" {
+ set description "next over start_reporter"
+ set command "next"
+ }
-re ".*TRY.*$gdb_prompt $" {
set description "next over TRY"
set command "next"
@@ -119,23 +119,7 @@ proc do_steps_and_nexts {} {
set description "step into captured_main (args)"
set command "step"
}
- -re ".*count . 0x3.*$gdb_prompt $" {
- set description "next over conditional stack alignment code 1"
- set command "next"
- }
- -re ".*if .i != 0.*$gdb_prompt $" {
- set description "next over conditional stack alignment code 2"
- set command "next"
- }
- -re ".*alloca .i - 4.*$gdb_prompt $" {
- set description "next over conditional stack alignment alloca"
- set command "next"
- }
- -re ".*dirsize = 1.*$gdb_prompt $" {
- set description "next over dirsize initialization"
- set command "next"
- }
- -re ".*dirarg = .* xmalloc.*$gdb_prompt $" {
+ -re ".*saved_command_line = .* xstrdup.*$gdb_prompt $" {
return
}
-re ".*setlocale .LC_MESSAGES,.*$gdb_prompt $" {
@@ -184,10 +168,6 @@ proc do_steps_and_nexts {} {
set description "step over gdb_sysroot initialization"
set command "step"
}
- -re ".*ndir = 0.*$gdb_prompt $" {
- set description "step over ndir initialization"
- set command "step"
- }
-re ".*instream = stdin.*$gdb_prompt $" {
set description "step over instream initialization"
set command "step"
@@ -199,11 +179,7 @@ proc do_steps_and_nexts {} {
-re ".*gdb_program_name = xstrdup.*$gdb_prompt $" {
set description "next over xstrdup"
set command "next"
- }
- -re ".*quit_flag = 0.*$gdb_prompt $" {
- set description "step over quit_flag initialization"
- set command "step"
- }
+ }
-re ".*gdb_stdout = stdio_fileopen .stdout.;.*$gdb_prompt $" {
set description "step over gdb_stdout initialization"
set command "step"
@@ -301,53 +277,6 @@ proc test_with_self { } {
do_steps_and_nexts
- gdb_test "print \"foo\"" ".\[0-9\]+ = \"foo\"" "print a string"
-
- # do_steps_and_nexts left us ready to execute an xmalloc call,
- # so give that a try.
- # If we don't actually enter the xmalloc call when we give a
- # step command that seems like a genuine bug. It seems to happen
- # on most RISC processors.
- # NOTE drow/2003-06-22: However, if we step back to the preceding two
- # lines, just keep stepping until we enter.
- set stepped_back 0
- setup_xfail "alpha-*-*" "mips-*-*"
- set description "step into xmalloc call"
- gdb_test_multiple "step" "$description" {
- -re "ncmd = 0;.*$gdb_prompt $" {
- set stepped_back 1
- send_gdb "step\n"
- exp_continue
- }
- -re ".*cmdarg = .* xmalloc.*$gdb_prompt $" {
- set stepped_back 1
- send_gdb "step\n"
- exp_continue
- }
- -re "dirsize = 1;.*$gdb_prompt $" {
- set stepped_back 1
- send_gdb "step\n"
- exp_continue
- }
- -re ".*dirarg = .* xmalloc.*$gdb_prompt $" {
- if { $stepped_back == 1 } {
- send_gdb "step\n"
- exp_continue
- } else {
- fail "$description"
- }
- }
- -re "xmalloc.*size=.*at.*utils.c.*$gdb_prompt $" {
- pass "$description"
- }
- -re ".*No such file or directory.\r\n$gdb_prompt $" {
- pass "$description (no source available)"
- }
- -re "A file or directory .* does not exist..\r\n$gdb_prompt $" {
- pass "$description (no source available)"
- }
- }
-
# start the "xgdb" process
if [target_info exists gdb,noinferiorio] {
# With no way to interact with the inferior GDB, all we can do