Re: Help request on making a gdb testsuite case

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2018-03-06 13:01, Andrey Utkin wrote:
> Hi GDB devs,
> 
> I have found that the case of restarting the debuggee in 
> extended-remote
> session 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 in
> commit 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 
> case
> in 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