This is the mail archive of the gdb-patches@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]

Re: [PATCH] testsuite tfind.exp: If current target don't support trace, try gdbserver.


On 03/29/2012 03:43 PM, Hui Zhu wrote:

> That is back to the old question I ask for, right? :)
> 
> Why the way try to make the trace function of GDB more easy be tested is not you want.

>

> And this way didn't affect current test.


We're going in circles.  I already explained why.  But let me try one last time.
We spawn the testsuite against a given target.  It's wrong to run _some_ tests
against _yet another_ target if not that first one.  The gdb.server/ tests are
special, and most scheduled for removal, exactly due to this issue.

The trace function of GDB is not special compared to any other feature not
supported by the native debugger.  If you spawn a test run to test the native
debugger, that's all that should be tested, with the features it doesn't support
skipped.  If you spawn a test run to test the sim, that's all that should be
tested, with the features it doesn't support skipped.  If you spawn a test run
to test a remote qemu, that's all that should be tested, with the features
it doesn't support skipped.  If you spawn a test run to test a gdbserver, that's
all that should be tested, with the features it doesn't support skipped.

People should already be testing routinely against both the native
target, and gdbserver.

So the benefits of leaving the test run to test the target that it is meant
to test should be obvious.  So, no, I'll strongly object to such patches.

Another example, imagine if native debugging already supported tracing, but then
some patch inadvertently broke that, but then the test harness spawns gdbserver
when the native target says "sorry I can't to tracing", and the test runs
against gdbserver instead.  You'd be masking the bug...

If you want to make things easier, make it simpler to run the testsuite
against the just built gdbserver, without having to install the
native-gdbserver.exp (and friends) board files elsewhere, for example, with
a new makefile target ('make check-gdbserver' or some such), that points SITE
at an site.exp in the GDB source tree, that picks up the board
files under src/gdb/testsuite/boards.

-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]