Re: gdb.objc/objcdecode.exp test error..

[Joel Brobecker <brobecker@adacore.com>]

> np, this is also duplicated in the 2 .exp files,
> i should figure out if i can somehow include it from the gdb.objc?

I'd say nah, let's keep it kiss for now.

> well, theres a lot of tests that pass that just involve various setup
> for the tests which fail, i think ideally, these would not be tests,
> but e.g. if i just do send_gdb I seem to run into lots of timing
> issues, i just kfailed the ones that do fail.

It's fine for them to be tests, even if they are very simple minded
and are not directly related to the issue we're trying to test. They
are still part of the scenario, and if something goes wrong, then we
get a FAIL. send_gdb should never ever be used in a testcase except
under peculiar conditions that gdb_test_multiple does not handle
already.  The send_gdb thing is not all that evil, it's just that
people tend to follow it up with an expect_gdb, which is usually
incomplete, and always a maintenance issue.

We can handle the change to lib/gdb.exp independently of the rest.

@@ -474,6 +474,11 @@ proc gdb_continue_to_breakpoint {name {location_pattern .*}} {
 	-re ".*$gdb_prompt $" {
 	    fail $full_name
 	}
+        -re ".*A problem internal to GDB has been detected" {
+             fail "$full_name (GDB internal error)"
+             gdb_internal_error_resync
+	}
+
 	timeout { 
 	    fail "$full_name (timeout)"
 	}

This is a perfect example of why send_gdb/expect_gdb is usually
a bad idea. This should be replaced by gdb_test_multiple. The whole
implementation can then be replaced by:

    gdb_test_mutiple "continue" $full_name {
        -re "Breakpoint .* (at|in) $location_pattern\r\n$gdb_prompt $" {
            pass $full_name
        }
    }

It could also possibly be replaced by a simple call to gdb_test, but
I think that gdb_test has a side-effect of appending a wildcard match
at the end of the given regexp. So it would transform $location_pattern
into $location_pattern followed by ".*".

-- 
Joel