This is the mail archive of the gdb-patches@sources.redhat.com 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: [RFA] Some testcases for long long bitfields


Here we go :-)

- which system was it tested on?

- loose this:
+# Please email any bugs, comments, and/or additions to this file to:
+# bug-gdb@prep.ai.mit.edu

- reword the tests from:
"bitfield uniqueness (u1)"
to something like:
	bitfield uniqueness; flags.u1 = 1
so that what's being tested is clearer and the names are unique.

- on similar lines, take the gdb.sum file from running this testand put it through 'uniq -d' s.fixing any duplicate

- use gdb_test_multiple
+    # Determine if the target has signed bitfields so we can xfail the
+    # the signed bitfield tests if it doesn't.
+    set no_signed 1
+    send_gdb "print i\n"
+    gdb_expect {
+	-re ".* = -32768.*$gdb_prompt $" {
+	    set no_signed 0
+	    pass "determining signed-ness of bitfields"
+	}

- Why? Or is this really a known bug?
+    if $no_signed then {
+	setup_xfail "*-*-*"
+    }
+    set test "set long long signed bitfield negative"
+    gdb_test_multiple "print flags.s2 = -1" $test {
+	-re "warning: Value does not fit.*$gdb_prompt $" {
+	    fail "$test"
+	    gdb_suppress_tests
+	}
+	-re "= -1.*$gdb_prompt $" {
+	    pass "$test"
+	}
+    }

- ditto?
+    if $no_signed then {
+	setup_xfail "*-*-*"
+    }
+    if [gdb_test "print flags" "u1 = 0, u2 = 4294967296, u3 = 0, s1 = 0, s2 = -1, s3 = 0.*" "long long bitfield values after set negative"] {
+	gdb_suppress_tests
+    }
+    gdb_stop_suppressing_tests;
+}

+bitfield_uniqueness

- delete this:
+if [istarget "mips-idt-*"] then {
+    # Restart because IDT/SIM runs out of file descriptors.
+    gdb_exit
+    gdb_start
+    gdb_reinitialize_dir $srcdir/$subdir
+    gdb_load ${binfile}
+}

- for all these:
+ if { ! [runto break5] } {
+ gdb_suppress_tests
+ }
perhaphs think about what I did for the sig*.exp tests - have main as a loop so that it looped around after each test sequence was finished - will on remote systems improve the performance somewhat. But what ever.


Once all this are addressed, post the update _along_ with the system tested on, and then it can be committed.

Andrew


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