[PATCH] skip break-entry.exp when using a stub

[PATCH] skip break-entry.exp when using a stub

[Nathan Froyd]

This patch skips gdb.base/break-entry.exp when using a stub.
prepare_for_testing already stopped the program at its entry, so the
test will not work correctly.

Tested with cross to powerpc-linux-gnu using gdbserver.  OK to commit?

-Nathan

	* gdb.base/break-entry.exp: Skip if using a stub.
---
 gdb/testsuite/gdb.base/break-entry.exp |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/gdb/testsuite/gdb.base/break-entry.exp b/gdb/testsuite/gdb.base/break-entry.exp
index d4b86a3..4e4515b 100644
--- a/gdb/testsuite/gdb.base/break-entry.exp
+++ b/gdb/testsuite/gdb.base/break-entry.exp
@@ -21,6 +21,15 @@ if { [prepare_for_testing ${testfile}.exp ${testfile} start.c {additional_flags=
     return -1
 }
 
+# If we're using a stub, we'll already be stopped at the entry point
+# when we connect.  Don't bother trying to work around this in the
+# testing below.
+
+if [target_info exists use_gdb_stub] {
+    untested ${testfile}.exp
+    return
+}
+
 set test "info files"
 set entry ""
 gdb_test_multiple $test $test {
-- 
1.6.3.2

Re: [PATCH] skip break-entry.exp when using a stub

[Pedro Alves]

On Friday 29 October 2010 20:20:40, Nathan Froyd wrote:
> This patch skips gdb.base/break-entry.exp when using a stub.
> prepare_for_testing already stopped the program at its entry, so the
> test will not work correctly.

This is okay, but I think the comment below could use
some clarification/expansion.

> +# If we're using a stub, we'll already be stopped at the entry point
> +# when we connect.  Don't bother trying to work around this in the
> +# testing below.

What do you think of something like this alternative:

# If we're using a stub, we'll already be debugging a live
# program and stopped at the entry point when we connect,
# and so runto below will issue a "continue", which always
# skips any breakpoint at PC.  When testing with a native
# target (or some other target that supports "run"), runto
# will do a "run", which 1. creates the process, leaving
# the PC at the entry point, just like the stub case, but then
# continues the process with the equivalent of "jump *$PC", which
# triggers any breakpoint at $PC.  The latter is what we want
# to test.

?  (may need copy&editing)

-- 
Pedro Alves

Re: [PATCH] skip break-entry.exp when using a stub

[Joel Brobecker]

> -Nathan
> 
> 	* gdb.base/break-entry.exp: Skip if using a stub.

I am not sure about one detail:

> +# If we're using a stub, we'll already be stopped at the entry point
> +# when we connect.  Don't bother trying to work around this in the
> +# testing below.
> +
> +if [target_info exists use_gdb_stub] {
> +    untested ${testfile}.exp
> +    return
> +}

I am not sure that the use of "untested" is correct, here. Looking
at the dejagnu documentation:

    UNTESTED
        A test was not run. This is a placeholder, used when there is no
        real test case yet. 

    untested "string"
        Declares a test was not run. untested writes in the log file
        a message beginning with `UNTESTED', appending the argument
        string. For example, you might use this in a dummy test whose
        only role is to record that a test does not yet exist for some
        feature. 

Perhaps we just ought to `return' directly. What do others think?

-- 
Joel

Re: [PATCH] skip break-entry.exp when using a stub

[Michael Snyder]

Joel Brobecker wrote:
>> -Nathan
>>
>> 	* gdb.base/break-entry.exp: Skip if using a stub.
> 
> I am not sure about one detail:
> 
>> +# If we're using a stub, we'll already be stopped at the entry point
>> +# when we connect.  Don't bother trying to work around this in the
>> +# testing below.
>> +
>> +if [target_info exists use_gdb_stub] {
>> +    untested ${testfile}.exp
>> +    return
>> +}
> 
> I am not sure that the use of "untested" is correct, here. Looking
> at the dejagnu documentation:
> 
>     UNTESTED
>         A test was not run. This is a placeholder, used when there is no
>         real test case yet. 
> 
>     untested "string"
>         Declares a test was not run. untested writes in the log file
>         a message beginning with `UNTESTED', appending the argument
>         string. For example, you might use this in a dummy test whose
>         only role is to record that a test does not yet exist for some
>         feature. 
> 
> Perhaps we just ought to `return' directly. What do others think?
> 

Yes, that's what I'd do.