Skip to content

Commit c073089

Browse files
Always quit GDB after running a dejagnu test case
That a third take on solving an issue with targets not being reset properly. It relies on GDB server (nSIM in this case) to implement k-packet to reset target. Typically gdb-comm.exp board used for nSIM-GDB testing reuses GDB instance, however that causes troubles in some cases: 1. Unfortunate combination of PC+BLINK registers causes a failed assertion in generic GDB code. Target should be reset before GDB disconnects from it. 2. GDB sometimes fails to properly load debug symbols from new file, at least when this file has asme name as before, but different contents. This problem is sporadic, so I'm not sure what are exact conditions for reprodcution, but having same time stamaps doesn't cause issue. To avoid this GDB should be restarted completely between tests. While restarting it will also send k-packet to target, which will rest it. Signed-off-by: Anton Kolesov <[email protected]>
1 parent c7a5522 commit c073089

File tree

1 file changed

+20
-0
lines changed

1 file changed

+20
-0
lines changed

dejagnu/nsim-extra.exp

Lines changed: 20 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -111,4 +111,24 @@ proc arc-nsim_reboot { connhost args } {
111111
return 1
112112
}
113113

114+
# There are problems with GDB loading new application with `file` command, at
115+
# least when new file has same filename as the old one. That problem is
116+
# not-deterministic and I wasn't able to trace down the source, however I see
117+
# that this happened between 7.5 and 7.6. To avoid troubles - restart GDB
118+
# completely. Note that it is known that GDB might misbehave when it connects
119+
# to target which has already set PC and BLINK register, so to avoid possible
120+
# issues gdbserver should be reset before disconnection. Here we rely on server
121+
# to implement k-packet, sent by GDB on "quit" command. Another option is to
122+
# reset registers manually or restart GDB-server completely. The latter is
123+
# highly undesirable, because it creates huge overhead in typical Dejagnu test
124+
# cases, which are very-very small, but there is lots of them.
125+
126+
# Standard gdb_comm_leave will simply disconnect from target and will reuse
127+
# same GDB for next test.
128+
proc gdb_comm_leave { } {
129+
global gdb_prompt
130+
verbose "ARC specific gdb_comm_leave"
131+
quit_gdb
132+
}
133+
114134
# vim: noexpandtab sts=4 ts=8:

0 commit comments

Comments
 (0)