This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 2018-03-06 13:01, Andrey Utkin wrote:
Hi GDB devs,I have found that the case of restarting the debuggee in extended-remotesession has been broken in GDB for undetermined, but quite long time (predating gdb 7.10.1). It got fixed in git master just recently, on February 15 by Yao Qi incommit 85046ae23f85 (thanks a lot!). Anyway, now I have an automated way to detect the bug which got fixed, and would like to turn it into a casein GDB test suite. # "./simple" is built from "int main(){return 0;}", must be unstripped timeout 4 "$GDB" \ -ex "target extended-remote | $GDBSERVER --once - ./simple" \ -ex 'break main' \ -ex 'set confirm off' \ -ex 'run' \ -ex 'quit' \ ; # buggy gdb would hang It is not obvious to me how to write such a testcase. There are three elements: the debuggee, the server process and the frontend process. I have very rough idea that some goodness to use is in lib/gdbserver-support.exp, and almost certainly i'll use gdb_target_cmd procedure, but beyond that, I'm pretty much lost. How would I specify a debuggee program, or where do I find one to reuse after other tests? Any help would be highly appreciated!
Hi Andrey,I'm a bit surprised that we don't already have a test that tries re-running an inferior. I ran the testsuite before and after that patch, and didn't see result change, so maybe we are indeed missing one to test this.
Normally, test cases don't care whether they are ran against a gdb that debugs natively or a gdb that connects to gdbserver. That is controlled when running the testsuite. By default, the testsuite will use a gdb that debugs natively, but when passing RUNTESTFLAGS="--target_board=native-extended_gdbserver", for example, it will use a gdb connected to a gdbserver (on localhost) with the extended-remote protocol.
I could only reproduce the bug when starting gdbserver with a binary file. However, with the native-extended-gdbserver board, gdbserver is started with --multi and no binary file specified. If we absolutely need to start gdbserver with non-standard arguments to reproduce the bug, then we would have to write a gdbserver-specific test and put it in testsuite/gdb.server. I suggest you look at the other files in this directory and steal some bits from them. You can then ask further questions about the bumps you hit (here, or on IRC).
Here are some details about running the tests: https://sourceware.org/gdb/wiki/TestingGDB Here are some details about writing tests: https://sourceware.org/gdb/wiki/GDBTestcaseCookbook Simon
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |