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

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

[Hui Zhu]

[-- Attachment #1: Type: text/plain, Size: 570 bytes --]

Hi,

When we want to test the trace function that in gdb.trace directory, we 
will got a lot of UNSUPPORTED.  To use this testcase, we need follow way 
in 
http://sourceware.org/gdb/wiki/TestingGDB#Testing_gdbserver_in_a_native_configuration.

So I post a patch add some code if current target don't support trace, 
try gdbserver in tfind.exp.
If this patch goes OK.  I will post patch for other testsuite that 
support by gdbserver.

Thanks.
Hui

2012-03-29  Hui Zhu  <hui_zhu@mentor.com>

	* gdb.trace/tfind.exp: If current target don't support trace,
	try gdbserver.

[-- Attachment #2: testsuite_trace_use_gdbserver.txt --]
[-- Type: text/plain, Size: 883 bytes --]

---
 testsuite/gdb.trace/tfind.exp |   21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

--- a/testsuite/gdb.trace/tfind.exp
+++ b/testsuite/gdb.trace/tfind.exp
@@ -36,10 +36,25 @@ gdb_test "tfind none"  ".*" ""
 runto_main
 gdb_reinitialize_dir $srcdir/$subdir
 
-if { ![gdb_target_supports_trace] } then {
-    unsupported "Current target does not support trace"
-    return 1;
+if ![gdb_target_supports_trace] {
+    load_lib gdbserver-support.exp
 
+    clean_restart $testfile
+
+    if { [skip_gdbserver_tests] } {
+	unsupported "target does not support trace"
+	return -1;
+    }
+
+    gdb_test "disconnect" ".*"
+
+    gdbserver_run ""
+    gdb_reinitialize_dir $srcdir/$subdir
+
+    if ![gdb_target_supports_trace] {
+	unsupported "target does not support trace"
+	return -1;
+    }
 }
 
 # If testing on a remote host, download the source file.

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

[Pedro Alves]

On 03/29/2012 10:17 AM, Hui Zhu wrote:

> Hi,
> 
> When we want to test the trace function that in gdb.trace directory, we will got a lot of UNSUPPORTED.  To use this testcase, we need follow way in http://sourceware.org/gdb/wiki/TestingGDB#Testing_gdbserver_in_a_native_configuration.
> 
> So I post a patch add some code if current target don't support trace, try gdbserver in tfind.exp.
> If this patch goes OK.  I will post patch for other testsuite that support by gdbserver.


NAK.  If the current target doesn't support tracing, the right thing to
do is to skip the test, as we do currently.

-- 
Pedro Alves

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

[Hui Zhu]

On 03/29/12 17:23, Pedro Alves wrote:
> On 03/29/2012 10:17 AM, Hui Zhu wrote:
>
>> Hi,
>>
>> When we want to test the trace function that in gdb.trace directory, we will got a lot of UNSUPPORTED.  To use this testcase, we need follow way in http://sourceware.org/gdb/wiki/TestingGDB#Testing_gdbserver_in_a_native_configuration.
>>
>> So I post a patch add some code if current target don't support trace, try gdbserver in tfind.exp.
>> If this patch goes OK.  I will post patch for other testsuite that support by gdbserver.
>
>
> NAK.  If the current target doesn't support tracing, the right thing to
> do is to skip the test, as we do currently.
>

That is because it didn't use target remote, most trace function is 
together with target remote, right?

Thanks,
Hui

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

[Pedro Alves]

On 03/29/2012 10:29 AM, Hui Zhu wrote:

> On 03/29/12 17:23, Pedro Alves wrote:
>> On 03/29/2012 10:17 AM, Hui Zhu wrote:
>>
>>> Hi,
>>>
>>> When we want to test the trace function that in gdb.trace directory, we will got a lot of UNSUPPORTED.  To use this testcase, we need follow way in http://sourceware.org/gdb/wiki/TestingGDB#Testing_gdbserver_in_a_native_configuration.
>>>
>>> So I post a patch add some code if current target don't support trace, try gdbserver in tfind.exp.
>>> If this patch goes OK.  I will post patch for other testsuite that support by gdbserver.
>>
>>
>> NAK.  If the current target doesn't support tracing, the right thing to
>> do is to skip the test, as we do currently.
>>
> 
> That is because it didn't use target remote, most trace function is together with target remote, right?


There are of course remote targets that also don't support tracing.  Not all GDBserver
ports support tracing, or we could even be testing against a server other than GDBserver
(qemu, for example).  Technically, native targets could also support tracing.  See e.g., Yao's
push towards using an IPA with the native target.

-- 
Pedro Alves

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

[Hui Zhu]

[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]

Hi Pedro,

On 03/29/12 17:46, Pedro Alves wrote:
> On 03/29/2012 10:29 AM, Hui Zhu wrote:
>
>> On 03/29/12 17:23, Pedro Alves wrote:
>>> On 03/29/2012 10:17 AM, Hui Zhu wrote:
>>>
>>>> Hi,
>>>>
>>>> When we want to test the trace function that in gdb.trace directory, we will got a lot of UNSUPPORTED.  To use this testcase, we need follow way in http://sourceware.org/gdb/wiki/TestingGDB#Testing_gdbserver_in_a_native_configuration.
>>>>
>>>> So I post a patch add some code if current target don't support trace, try gdbserver in tfind.exp.
>>>> If this patch goes OK.  I will post patch for other testsuite that support by gdbserver.
>>>
>>>
>>> NAK.  If the current target doesn't support tracing, the right thing to
>>> do is to skip the test, as we do currently.
>>>
>>
>> That is because it didn't use target remote, most trace function is together with target remote, right?
>
>
> There are of course remote targets that also don't support tracing.  Not all GDBserver
> ports support tracing, or we could even be testing against a server other than GDBserver
> (qemu, for example).  Technically, native targets could also support tracing.  See e.g., Yao's
> push towards using an IPA with the native target.
>

I agree with you.  It really affect current test.

So I add a var TRACE_TRY_GDBSERVER in this check, then the test will try 
gdbserver only when set TRACE_TRY_GDBSERVER.  Then for the people that 
don't care about try gdbserver when test tracepoint, he can set 
TRACE_TRY_GDBSERVER with himself.

Thanks,
Hui

2012-03-29  Hui Zhu  <hui_zhu@mentor.com>

	* gdb.trace/tfind.exp: If current target don't support trace,
	try gdbserver.


[-- Attachment #2: testsuite_trace_use_gdbserver.txt --]
[-- Type: text/plain, Size: 1037 bytes --]

---
 testsuite/gdb.trace/tfind.exp |   28 +++++++++++++++++++++++++---
 1 file changed, 25 insertions(+), 3 deletions(-)

--- a/testsuite/gdb.trace/tfind.exp
+++ b/testsuite/gdb.trace/tfind.exp
@@ -36,10 +36,32 @@ gdb_test "tfind none"  ".*" ""
 runto_main
 gdb_reinitialize_dir $srcdir/$subdir
 
-if { ![gdb_target_supports_trace] } then {
-    unsupported "Current target does not support trace"
-    return 1;
+if ![gdb_target_supports_trace] {
+    global TRACE_TRY_GDBSERVER
+
+    if ![info exists TRACE_TRY_GDBSERVER] {
+	unsupported "target does not support trace"
+	return -1;
+    }
+
+    load_lib gdbserver-support.exp
+
+    clean_restart $testfile
 
+    if { [skip_gdbserver_tests] } {
+	unsupported "target does not support trace"
+	return -1;
+    }
+
+    gdb_test "disconnect" ".*"
+
+    gdbserver_run ""
+    gdb_reinitialize_dir $srcdir/$subdir
+
+    if ![gdb_target_supports_trace] {
+	unsupported "target does not support trace"
+	return -1;
+    }
 }
 
 # If testing on a remote host, download the source file.

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

[Pedro Alves]

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

> So I add a var TRACE_TRY_GDBSERVER in this check, then the test will try gdbserver only when set TRACE_TRY_GDBSERVER.  Then for the people that don't care about try gdbserver when test tracepoint, he can set TRACE_TRY_GDBSERVER with himself.


NAK.  Please just give up the patch.  It is contrary to the direction we want.

-- 
Pedro Alves

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

[Hui Zhu]

On 03/29/12 22:13, Pedro Alves wrote:
> On 03/29/2012 03:01 PM, Hui Zhu wrote:
>
>> So I add a var TRACE_TRY_GDBSERVER in this check, then the test will try gdbserver only when set TRACE_TRY_GDBSERVER.  Then for the people that don't care about try gdbserver when test tracepoint, he can set TRACE_TRY_GDBSERVER with himself.
>
>
> NAK.  Please just give up the patch.  It is contrary to the direction we want.
>

Sorry I don't understand 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.

Thanks,
Hui

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

[Pedro Alves]

Let me put this another way.  If when testing against a remote target, we find
ourselves testing a feature that happens to not be supported by the currently connected
remote target, but may be supported by the native target, do you think a test should go
through contortions to run against the native target?  (the answer is no).

-- 
Pedro Alves

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

[Hui Zhu]

On 03/29/12 22:25, Pedro Alves wrote:
> Let me put this another way.  If when testing against a remote target, we find
> ourselves testing a feature that happens to not be supported by the currently connected
> remote target, but may be supported by the native target, do you think a test should go
> through contortions to run against the native target?  (the answer is no).
>

Yes, I know you worry about it and I agree with it.  So I add 
TRACE_TRY_GDBSERVER.

For the test that against a remote target or other normal way, because 
TRACE_TRY_GDBSERVER is not set.  Test will not auto try target remote 
when current target didn't support trace.

When we want test the function inside the GDB, we can set 
TRACE_TRY_GDBSERVER, then test will use gdbserver if need.

Thanks,
Hui

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

[Pedro Alves]

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

> On 03/29/12 22:25, Pedro Alves wrote:
>> Let me put this another way.  If when testing against a remote target, we find
>> ourselves testing a feature that happens to not be supported by the currently connected
>> remote target, but may be supported by the native target, do you think a test should go
>> through contortions to run against the native target?  (the answer is no).
>>
> 
> Yes, I know you worry about it and I agree with it.  So I add TRACE_TRY_GDBSERVER.
> 
> For the test that against a remote target or other normal way, because TRACE_TRY_GDBSERVER is not set.  Test will not auto try target remote when current target didn't support trace.
> 
> When we want test the function inside the GDB, we can set TRACE_TRY_GDBSERVER, then test will use gdbserver if need.


Sorry, no, we don't want to add this.  Just run the testsuite against gdbserver if that's what you want to test.

-- 
Pedro Alves

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

[Hui Zhu]

On 03/29/12 22:39, Pedro Alves wrote:
> On 03/29/2012 03:38 PM, Hui Zhu wrote:
>
>> On 03/29/12 22:25, Pedro Alves wrote:
>>> Let me put this another way.  If when testing against a remote target, we find
>>> ourselves testing a feature that happens to not be supported by the currently connected
>>> remote target, but may be supported by the native target, do you think a test should go
>>> through contortions to run against the native target?  (the answer is no).
>>>
>>
>> Yes, I know you worry about it and I agree with it.  So I add TRACE_TRY_GDBSERVER.
>>
>> For the test that against a remote target or other normal way, because TRACE_TRY_GDBSERVER is not set.  Test will not auto try target remote when current target didn't support trace.
>>
>> When we want test the function inside the GDB, we can set TRACE_TRY_GDBSERVER, then test will use gdbserver if need.
>
>
> Sorry, no, we don't want to add this.  Just run the testsuite against gdbserver if that's what you want to test.
>

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.

Thanks,
Hui

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

[Pedro Alves]

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

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

[Hui Zhu]

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