Re: GDB testsuite questions

[Simon Marchi <simon dot marchi at ericsson dot com>]

Hi David,

On 2014-11-11 01:01 PM, David Taylor wrote:
> It's been more than a decade since I did anything significant in DejaGNU
> or Tcl (and I've never really cared for Tcl as a language), so these
> questions are probably easy for someone who uses it regularly.
> 
> I have two sets of changes to GDB held up while I figure these out --
> 
> . how to grab part of the each of the responses to multiple gdb commands
> and do arithmetric on the result to decide whether the test failed or
> passed.
> 
> More specifically testing a fix for bug 17520 (structure offset wrong
> when 1/4 GB or greater).
> 
> While more of our structures are 'reasonably' sized, a few are rather
> large.  If you have a structure where some members are 1/4 GB or more
> bytes from the start of the structure, GDB will calculate the wrong
> offset for the member.
> 
> So, given the structure:
> 
>     struct big_struct
>     {
>       char first[0x10000000 + 16];
>       long second;
>     } big_struct;
> 
> in GDB 7.8, I did:
> 
>    (gdb) print &big_struct
>     $1 = (struct big_struct *) 0x601040 <big_struct>
>     (gdb) print &big_struct.second
>     $2 = (long *) 0xfffffffff0601050
> 
> So, I want to take the addresses and compare the difference vs what it
> should be.

I don't know how to capture part of the output of a test to a tcl variable,
so you'll have to wait for someone else to answer that.

You could use something like the following command, which should be easy to
test with a single gdb_test.

    (gdb) p/x ((void *) &big_struct.second) - ((void *) &big_struct)
    $2 = 0xfffffffff0000010

However, it would still be nice to test it the way you suggested (get both
addresses and subtract in tcl), since my way involves the gdb code for
subtracting pointers, which is also subject to bugs related to big numbers.

> . I also need to be able to disable it for targets that don't have
> enough memory.  The program does not need to be downloaded or run; but,
> if the link fails, disable the test.

I suppose you are using prepare_for_testing at the beginning of your test.
If so, if you use it as many other tests do:

    if {[prepare_for_testing $testfile.exp $testfile $srcfile $compile_flags]} {
        untested $testfile.exp
        return -1
    }

then it will skip the test in the event of a build error.

> As part of the bug fix a total of 33 files were modified.  There are no
> regressions on x86-64 Linux, but there needs to be a new test to make
> sure the problem does not reoccur.

Indeed!

> The other set of changes that is yet to be submitted for approval
> involves extending the agent bytecode expressions to allow setting
> variables (useful when a breakpoint is hit).  How do I force the
> testsuite to run against gdbserver?  I have gdbserver changes and I want
> them tested.  I also need to write the new tests...

If you are asking how to run the tests with gdbserver, you can refer to this:
https://sourceware.org/gdb/wiki/TestingGDB#Testing_gdbserver_in_a_native_configuration

which in turns points you to the header of gdb/testsuite/boards/native-gdbserver.exp.

If you want to limit the scope of your test (only run it when using a remote target),
you can use "is_remote". There are plenty of examples in the testsuite.

If you want to limit the scope to _gdbserver_ specifically (and not any remote), then
it's a bit more tricky. There is an example of it in gdb.trace/qtro.exp. I have submitted
a patch some time ago about introducing a "target_is_gdbserver" procedure, which would
take care of that for you [1], but it's still pending.

Simon

[1] https://sourceware.org/ml/gdb-patches/2014-09/msg00697.html