> First there are duplicate "${test}" names in the output,
> and some of them PASS and some of them FAIL.  Confusion!

Oops, they snuck back in :-(

> The real problem is what to do when the notorious
> "location at which to store the function's return value is unknown"
> happens.  If that message happens, perhaps it is a KFAIL because
> gdb cannot do what the user asked.  Or perhaps it is okay because
> a message was printed.  I'm leaning towards the KFAIL, myself.
> 
> But the next bit of code:
> 
>   # Finally check that the value returned ended up in "L${n}".
>   setup_fails ${fails} gdb/1444
>   gdb_test "p/c L${n}" " = [foo ${n}]" "${test}"
> 
> If "location unknown" has occurred, then it's not even worthwhile
> to execute this at all.  Once gdb has informed the user about
> "location unknown" then there should be no expectation on the
> part of the user that the return value will get stored into memory.

Checking my notes.  There are two things being tested here:

- that return/finish really did occure
GDB 6.0 was doing something like this:
	(gdb) return foo1
	Return from fun1? y
	Couldn't find location of return type
	(gdb) list
	No frame
Even though the return was performed, GDB lost the current frame and 
forgot to print the new source and line.  (I can't tell you exactly what 
  it did because GDB 6.0 dies a death with this test case on PPC :-/).

- the value was returned
The test is actually pretty robust.  For a struct return, the global 
won't be modified (still contains zeds).

I've modified the testcase to detect/report this.

> Maybe gdb needs to print an additional message to make it
> more clear to the user:
> 
>   The location at which to store the function's return value is unknown.
>   If you continue, the return value that you specified will be ignored.
>   Make fun1 return now? (y or n) y

Like it, yes definitly.

> Then in the test script, if you get "location unknown", issue a KFAIL
> (or do whatever) and skip a test or two.

Attatched is todays version.  I think the way the fails are listed is 
now "ok".  Need to add more comments.

Andrew