public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [patch, testsuite] further robustify gdb.base/bp-permanent.exp
@ 2015-07-30  4:07 Sandra Loosemore
  2015-08-03 13:22 ` Pedro Alves
  0 siblings, 1 reply; 2+ messages in thread
From: Sandra Loosemore @ 2015-07-30  4:07 UTC (permalink / raw)
  To: gdb-patches

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

When I was testing the Nios II R2 patch I posted earlier today, I saw a 
lot of failures from gdb.base/bp-permanent.exp.  Upon investigation, I 
realized that this was a due to a quirk of the simulator we have 
available.  Apparently, its execution engine maintains its own view of 
the .text section and breakpoints set through the debug interface are 
not visible to the running program.  This means that the setup function 
in the program is stashing away a copy of the original NOP instruction 
at the breakpoint location, rather than the breakpoint instruction 
inserted by GDB, and when the .exp file thinks it is writing a permanent 
breakpoint in fact it is just telling the target to write a NOP to a 
location that already contains one.  :-S

Anyway, it is clear that if the program runs to termination instead of 
stopping where GDB expects, none of the remaining tests are going to do 
anything useful, so we might just as well report that the test is 
unsupported and return.

OK to commit?

-Sandra


[-- Attachment #2: gdb-bp.log --]
[-- Type: text/x-log, Size: 186 bytes --]

2015-07-29  Sandra Loosemore  <sandra@codesourcery.com>

	gdb/testsuite/
	* gdb.base/bp-permanent.exp: Report test as unsupported if
	the target cannot stop at the permanent breakpoint.

[-- Attachment #3: gdb-bp.patch --]
[-- Type: text/x-patch, Size: 1210 bytes --]

diff --git a/gdb/testsuite/gdb.base/bp-permanent.exp b/gdb/testsuite/gdb.base/bp-permanent.exp
index cbdbc75..44609ed 100644
--- a/gdb/testsuite/gdb.base/bp-permanent.exp
+++ b/gdb/testsuite/gdb.base/bp-permanent.exp
@@ -123,8 +123,21 @@ proc test {always_inserted sw_watchpoint} {
     with_test_prefix "basics" {
 	# Run to the permanent breakpoint, just to make sure we've inserted it
 	# correctly.
-	gdb_test "continue" "Program received signal SIGTRAP.*" \
-	    "permanent breakpoint causes random signal"
+	# If the target fails to stop, the remainder of the test will not work
+	# so just return.  This can happen on some simulator targets where
+	# the running program doesn't see breakpoints that are visible to
+	# the execution engine, or where writes to the .text section are
+	# quietly ignored.
+	set test "permanent breakpoint causes random signal"
+	gdb_test_multiple "continue" $test {
+	    -re "exited normally.*$gdb_prompt $" {
+	        unsupported "failed to stop at permanent breakpoint"
+		return
+	    }
+	    -re "Program received signal SIGTRAP.*" {
+	    	pass $test
+	    }
+	}
 
 	# Now set a breakpoint on top, thus creating a permanent breakpoint.
 	gdb_breakpoint "$line_bp"

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [patch, testsuite] further robustify gdb.base/bp-permanent.exp
  2015-07-30  4:07 [patch, testsuite] further robustify gdb.base/bp-permanent.exp Sandra Loosemore
@ 2015-08-03 13:22 ` Pedro Alves
  0 siblings, 0 replies; 2+ messages in thread
From: Pedro Alves @ 2015-08-03 13:22 UTC (permalink / raw)
  To: Sandra Loosemore, gdb-patches

On 07/30/2015 05:05 AM, Sandra Loosemore wrote:
> When I was testing the Nios II R2 patch I posted earlier today, I saw a 
> lot of failures from gdb.base/bp-permanent.exp.  Upon investigation, I 
> realized that this was a due to a quirk of the simulator we have 
> available.  Apparently, its execution engine maintains its own view of 
> the .text section and breakpoints set through the debug interface are 
> not visible to the running program.  This means that the setup function 
> in the program is stashing away a copy of the original NOP instruction 
> at the breakpoint location, rather than the breakpoint instruction 
> inserted by GDB, and when the .exp file thinks it is writing a permanent 
> breakpoint in fact it is just telling the target to write a NOP to a 
> location that already contains one.  :-S
> 
> Anyway, it is clear that if the program runs to termination instead of 
> stopping where GDB expects, none of the remaining tests are going to do 
> anything useful, so we might just as well report that the test is 
> unsupported and return.
> 
> OK to commit?

> +	set test "permanent breakpoint causes random signal"
> +	gdb_test_multiple "continue" $test {
> +	    -re "exited normally.*$gdb_prompt $" {
> +	        unsupported "failed to stop at permanent breakpoint"
> +		return
> +	    }
> +	    -re "Program received signal SIGTRAP.*" {

This needs to end with "$gdb_prompt $" too.

OK with that change.

> +	    	pass $test
> +	    }
> +	}
>  
>  	# Now set a breakpoint on top, thus creating a permanent breakpoint.
>  	gdb_breakpoint "$line_bp"
> 


Thanks,
Pedro Alves

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-08-03 13:22 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-30  4:07 [patch, testsuite] further robustify gdb.base/bp-permanent.exp Sandra Loosemore
2015-08-03 13:22 ` Pedro Alves

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).