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

[Hui Zhu <hui_zhu@mentor.com>]

On 03/29/12 22:59, Pedro Alves wrote:
> 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.
>

OK.  Thanks for your clear mail.  I got it.

Best,
Hui