RFA: tolerate unavailable struct return values

RFA: tolerate unavailable struct return values

[Jim Blandy]

On some architectures, it's impossible for GDB to find structs
returned by value.  These shouldn't be failures.  Should they be
passes?

2001-11-29  Jim Blandy  <jimb@redhat.com>

	If GDB says it can't find the struct the function returned, treat
	that as an expected failure.
	* gdb.base/structs.exp (call_struct_func): New function.
	(do_function_calls): Use call_struct_func to call the functions
	returning structs.

Index: gdb/testsuite/gdb.base/structs.exp
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.base/structs.exp,v
retrieving revision 1.17
diff -c -r1.17 structs.exp
*** gdb/testsuite/gdb.base/structs.exp	2001/08/09 18:02:02	1.17
--- gdb/testsuite/gdb.base/structs.exp	2001/11/29 17:46:25
***************
*** 54,59 ****
--- 54,85 ----
      continue
  }
  
+ 
+ # Call FUNC with no arguments, and expect to see the regexp RESULT in
+ # the output.  If we get back the error message "Function return value
+ # unknown", call that an expected failure; on some architectures, it's
+ # impossible to find structs returned by value reliably.
+ proc call_struct_func { func result } {
+     global gdb_prompt
+     
+     set command "p ${func}()"
+     send_gdb "${command}\n"
+     gdb_expect {
+         -re "$result\[\r\n\]+$gdb_prompt $" {
+             pass "$command"
+         }
+         -re "Function return value unknown.\[\r\n\]+$gdb_prompt $" {
+             xfail "$command"
+         }
+         -re "$gdb_prompt $" {
+             fail "$command"
+         }
+         timeout {
+             fail "$command (timeout)"
+         }
+     }
+ }
+ 
  # FIXME:  Before calling this proc, we should probably verify that
  # we can call inferior functions and get a valid integral value
  # returned.
***************
*** 67,85 ****
      global gdb_prompt
  
      # First, call the "fun" functions and examine the value they return.
!     gdb_test "p fun1()" " = {a = 49 '1'}"
!     gdb_test "p fun2()" " = {a = 97 'a', b = 98 'b'}"
!     gdb_test "p fun3()" " = {a = 65 'A', b = 66 'B', c = 67 'C'}"
!     gdb_test "p fun4()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4'}"
!     gdb_test "p fun5()" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e'}"
!     gdb_test "p fun6()" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F'}"
!     gdb_test "p fun7()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7'}"
!     gdb_test "p fun8()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8'}"
!     gdb_test "p fun9()" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i'}"
!     gdb_test "p fun10()" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J'}"
!     gdb_test "p fun11()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8', i = 57 '9', j = 65 'A', k = 66 'B'}"
!     gdb_test "p fun12()" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J', k = 75 'K', l = 76 'L'}"
!     gdb_test "p fun16()" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i', j = 106 'j', k = 107 'k', l = 108 'l', m = 109 'm', n = 110 'n', o = 111 'o', p = 112 'p'}"
  
      # Now call the Fun functions to set the L* variables.  This
      # tests that gdb properly passes structures to functions.
--- 93,111 ----
      global gdb_prompt
  
      # First, call the "fun" functions and examine the value they return.
!     call_struct_func "fun1" " = {a = 49 '1'}"
!     call_struct_func "fun2" " = {a = 97 'a', b = 98 'b'}"
!     call_struct_func "fun3" " = {a = 65 'A', b = 66 'B', c = 67 'C'}"
!     call_struct_func "fun4" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4'}"
!     call_struct_func "fun5" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e'}"
!     call_struct_func "fun6" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F'}"
!     call_struct_func "fun7" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7'}"
!     call_struct_func "fun8" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8'}"
!     call_struct_func "fun9" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i'}"
!     call_struct_func "fun10" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J'}"
!     call_struct_func "fun11" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8', i = 57 '9', j = 65 'A', k = 66 'B'}"
!     call_struct_func "fun12" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J', k = 75 'K', l = 76 'L'}"
!     call_struct_func "fun16" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i', j = 106 'j', k = 107 'k', l = 108 'l', m = 109 'm', n = 110 'n', o = 111 'o', p = 112 'p'}"
  
      # Now call the Fun functions to set the L* variables.  This
      # tests that gdb properly passes structures to functions.

Re: RFA: tolerate unavailable struct return values

[Michael Snyder]

Jim Blandy wrote:
> 
> On some architectures, it's impossible for GDB to find structs
> returned by value.  These shouldn't be failures.  Should they be
> passes?

I kinda like the idea of their being xfails.  The functionality
is not there, it's just not a surprise.


> 
> 2001-11-29  Jim Blandy  <jimb@redhat.com>
> 
>         If GDB says it can't find the struct the function returned, treat
>         that as an expected failure.
>         * gdb.base/structs.exp (call_struct_func): New function.
>         (do_function_calls): Use call_struct_func to call the functions
>         returning structs.
> 
> Index: gdb/testsuite/gdb.base/structs.exp
> ===================================================================
> RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.base/structs.exp,v
> retrieving revision 1.17
> diff -c -r1.17 structs.exp
> *** gdb/testsuite/gdb.base/structs.exp  2001/08/09 18:02:02     1.17
> --- gdb/testsuite/gdb.base/structs.exp  2001/11/29 17:46:25
> ***************
> *** 54,59 ****
> --- 54,85 ----
>       continue
>   }
> 
> +
> + # Call FUNC with no arguments, and expect to see the regexp RESULT in
> + # the output.  If we get back the error message "Function return value
> + # unknown", call that an expected failure; on some architectures, it's
> + # impossible to find structs returned by value reliably.
> + proc call_struct_func { func result } {
> +     global gdb_prompt
> +
> +     set command "p ${func}()"
> +     send_gdb "${command}\n"
> +     gdb_expect {
> +         -re "$result\[\r\n\]+$gdb_prompt $" {
> +             pass "$command"
> +         }
> +         -re "Function return value unknown.\[\r\n\]+$gdb_prompt $" {
> +             xfail "$command"
> +         }
> +         -re "$gdb_prompt $" {
> +             fail "$command"
> +         }
> +         timeout {
> +             fail "$command (timeout)"
> +         }
> +     }
> + }
> +
>   # FIXME:  Before calling this proc, we should probably verify that
>   # we can call inferior functions and get a valid integral value
>   # returned.
> ***************
> *** 67,85 ****
>       global gdb_prompt
> 
>       # First, call the "fun" functions and examine the value they return.
> !     gdb_test "p fun1()" " = {a = 49 '1'}"
> !     gdb_test "p fun2()" " = {a = 97 'a', b = 98 'b'}"
> !     gdb_test "p fun3()" " = {a = 65 'A', b = 66 'B', c = 67 'C'}"
> !     gdb_test "p fun4()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4'}"
> !     gdb_test "p fun5()" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e'}"
> !     gdb_test "p fun6()" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F'}"
> !     gdb_test "p fun7()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7'}"
> !     gdb_test "p fun8()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8'}"
> !     gdb_test "p fun9()" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i'}"
> !     gdb_test "p fun10()" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J'}"
> !     gdb_test "p fun11()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8', i = 57 '9', j = 65 'A', k = 66 'B'}"
> !     gdb_test "p fun12()" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J', k = 75 'K', l = 76 'L'}"
> !     gdb_test "p fun16()" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i', j = 106 'j', k = 107 'k', l = 108 'l', m = 109 'm', n = 110 'n', o = 111 'o', p = 112 'p'}"
> 
>       # Now call the Fun functions to set the L* variables.  This
>       # tests that gdb properly passes structures to functions.
> --- 93,111 ----
>       global gdb_prompt
> 
>       # First, call the "fun" functions and examine the value they return.
> !     call_struct_func "fun1" " = {a = 49 '1'}"
> !     call_struct_func "fun2" " = {a = 97 'a', b = 98 'b'}"
> !     call_struct_func "fun3" " = {a = 65 'A', b = 66 'B', c = 67 'C'}"
> !     call_struct_func "fun4" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4'}"
> !     call_struct_func "fun5" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e'}"
> !     call_struct_func "fun6" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F'}"
> !     call_struct_func "fun7" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7'}"
> !     call_struct_func "fun8" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8'}"
> !     call_struct_func "fun9" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i'}"
> !     call_struct_func "fun10" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J'}"
> !     call_struct_func "fun11" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8', i = 57 '9', j = 65 'A', k = 66 'B'}"
> !     call_struct_func "fun12" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J', k = 75 'K', l = 76 'L'}"
> !     call_struct_func "fun16" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i', j = 106 'j', k = 107 'k', l = 108 'l', m = 109 'm', n = 110 'n', o = 111 'o', p = 112 'p'}"
> 
>       # Now call the Fun functions to set the L* variables.  This
>       # tests that gdb properly passes structures to functions.

Re: RFA: tolerate unavailable struct return values

[Daniel Jacobowitz]

On Thu, Nov 29, 2001 at 05:09:13PM -0500, Jim Blandy wrote:
> 
> On some architectures, it's impossible for GDB to find structs
> returned by value.  These shouldn't be failures.  Should they be
> passes?

Out of curiousity, which architectures?  And to be pedantic, I suspect
that it might be "not always possible" rather than actually impossible.

Nit-picking aside, I agree with Michael.  This is the most appropriate
use for XFAIL, as opposed to some of the other things we use it for :)

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: tolerate unavailable struct return values

[Jim Blandy]

Tom Tromey <tromey@redhat.com> writes:
> Jim> On some architectures, it's impossible for GDB to find structs
> Jim> returned by value.  These shouldn't be failures.  Should they be
> Jim> passes?
> 
> Dejagnu also knows about "UNTESTED" and "UNSUPPORTED".
> See (dejagnu)Posix

That sounds right.  Revised patch:

2001-11-29  Jim Blandy  <jimb@redhat.com>

	If GDB says it can't find the struct the function returned, report
	those tests as `unsupported'.
	* gdb.base/structs.exp (call_struct_func): New function.
	(do_function_calls): Use call_struct_func to call the functions
	returning structs.

Index: gdb/testsuite/gdb.base/structs.exp
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.base/structs.exp,v
retrieving revision 1.17
diff -c -r1.17 structs.exp
*** gdb/testsuite/gdb.base/structs.exp	2001/08/09 18:02:02	1.17
--- gdb/testsuite/gdb.base/structs.exp	2001/11/30 06:37:45
***************
*** 54,59 ****
--- 54,85 ----
      continue
  }
  
+ 
+ # Call FUNC with no arguments, and expect to see the regexp RESULT in
+ # the output.  If we get back the error message "Function return value
+ # unknown", call that an expected failure; on some architectures, it's
+ # impossible to find structs returned by value reliably.
+ proc call_struct_func { func result } {
+     global gdb_prompt
+     
+     set command "p ${func}()"
+     send_gdb "${command}\n"
+     gdb_expect {
+         -re "$result\[\r\n\]+$gdb_prompt $" {
+             pass "$command"
+         }
+         -re "Function return value unknown.\[\r\n\]+$gdb_prompt $" {
+             unsupported "$command"
+         }
+         -re "$gdb_prompt $" {
+             fail "$command"
+         }
+         timeout {
+             fail "$command (timeout)"
+         }
+     }
+ }
+ 
  # FIXME:  Before calling this proc, we should probably verify that
  # we can call inferior functions and get a valid integral value
  # returned.
***************
*** 67,85 ****
      global gdb_prompt
  
      # First, call the "fun" functions and examine the value they return.
!     gdb_test "p fun1()" " = {a = 49 '1'}"
!     gdb_test "p fun2()" " = {a = 97 'a', b = 98 'b'}"
!     gdb_test "p fun3()" " = {a = 65 'A', b = 66 'B', c = 67 'C'}"
!     gdb_test "p fun4()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4'}"
!     gdb_test "p fun5()" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e'}"
!     gdb_test "p fun6()" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F'}"
!     gdb_test "p fun7()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7'}"
!     gdb_test "p fun8()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8'}"
!     gdb_test "p fun9()" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i'}"
!     gdb_test "p fun10()" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J'}"
!     gdb_test "p fun11()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8', i = 57 '9', j = 65 'A', k = 66 'B'}"
!     gdb_test "p fun12()" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J', k = 75 'K', l = 76 'L'}"
!     gdb_test "p fun16()" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i', j = 106 'j', k = 107 'k', l = 108 'l', m = 109 'm', n = 110 'n', o = 111 'o', p = 112 'p'}"
  
      # Now call the Fun functions to set the L* variables.  This
      # tests that gdb properly passes structures to functions.
--- 93,111 ----
      global gdb_prompt
  
      # First, call the "fun" functions and examine the value they return.
!     call_struct_func "fun1" " = {a = 49 '1'}"
!     call_struct_func "fun2" " = {a = 97 'a', b = 98 'b'}"
!     call_struct_func "fun3" " = {a = 65 'A', b = 66 'B', c = 67 'C'}"
!     call_struct_func "fun4" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4'}"
!     call_struct_func "fun5" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e'}"
!     call_struct_func "fun6" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F'}"
!     call_struct_func "fun7" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7'}"
!     call_struct_func "fun8" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8'}"
!     call_struct_func "fun9" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i'}"
!     call_struct_func "fun10" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J'}"
!     call_struct_func "fun11" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8', i = 57 '9', j = 65 'A', k = 66 'B'}"
!     call_struct_func "fun12" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J', k = 75 'K', l = 76 'L'}"
!     call_struct_func "fun16" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i', j = 106 'j', k = 107 'k', l = 108 'l', m = 109 'm', n = 110 'n', o = 111 'o', p = 112 'p'}"
  
      # Now call the Fun functions to set the L* variables.  This
      # tests that gdb properly passes structures to functions.

Re: RFA: tolerate unavailable struct return values

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> On Thu, Nov 29, 2001 at 05:09:13PM -0500, Jim Blandy wrote:
> > 
> > On some architectures, it's impossible for GDB to find structs
> > returned by value.  These shouldn't be failures.  Should they be
> > passes?
> 
> Out of curiousity, which architectures?  And to be pedantic, I suspect
> that it might be "not always possible" rather than actually
> impossible.

The one I have in mind is the S/390, although I'm pretty sure there
are others.  I've included the bug report I sent to the S/390 GCC
maintainers below.

One approach would be to hope that the return buffer's address was
still there in the register it was passed in.  But there's no way to
tell when you're wrong.  GDB will just print garbage, and the user
will think their program is wrong.  Better to simply say, "I can't
find this information reliably", and let the user, who knows their
program, find another way to get the info --- setting a breakpoint on
the return statement, or looking at where the caller put the
structure.


------- Start of forwarded message -------
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Hartmut Penner <hpenner@de.ibm.com>,
	Ulrich Weigand <uweigand@de.ibm.com>
Cc: Chris Moller <cmoller@redhat.com>,
	Matt Hiller <hiller@cygnus.com>
Subject: GDB unable to find structs returned by value using S/390 ABI 
Message-Id: <20011129190712.6AA5D5E9DB@zwingli.cygnus.com>
Date: Thu, 29 Nov 2001 14:07:12 -0500 (EST)


Given the way the S/390 Linux ABI specifies functions should return
structures by value, it is sometimes impossible for GDB to find
functions' return values.  There is a simple fix for this which is
backwards binary compatible with existing code; I don't think it will
have much impact on performance.

According to the ABI, structures which are one, two, four, or eight
bytes long must be returned by value in registers r2 and r3.  These
structures pose no problem for GDB.  However, the ABI specifies that
all other structures should be written to a buffer allocated by the
caller, whose address is passed to the callee as an "invisible" first
argument, in r2.  GDB is unable to find structs returned this way.

Suppose the user is running their program under GDB, and stops
execution in the middle of a function which will return a structure by
value.  The user then types the 'finish' command, which runs the
current function call to completion, and prints the value it returns.

By the time the function has returned to its caller, it will have
stored the returned struct in the caller's buffer.  Unfortunately, GDB
has no way at this point to find out where this buffer is.  The caller
passed it to the callee in r2, but the callee is free to do whatever
it pleases with that address; r2's value is unspecified upon return.

I suggest that we amend the ABI to require the callee to return the
address of the buffer holding the returned struct in r2.  This will
allow GDB to reliably find the buffer.  Since the pointer to the
buffer is live until the return value has been computed anyway, this
requirement shouldn't significantly increase register pressure in the
callee.

------- End of forwarded message -------

Re: RFA: tolerate unavailable struct return values

[Daniel Jacobowitz]

On Fri, Nov 30, 2001 at 03:49:52PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> > On Thu, Nov 29, 2001 at 05:09:13PM -0500, Jim Blandy wrote:
> > > 
> > > On some architectures, it's impossible for GDB to find structs
> > > returned by value.  These shouldn't be failures.  Should they be
> > > passes?
> > 
> > Out of curiousity, which architectures?  And to be pedantic, I suspect
> > that it might be "not always possible" rather than actually
> > impossible.
> 
> The one I have in mind is the S/390, although I'm pretty sure there
> are others.  I've included the bug report I sent to the S/390 GCC
> maintainers below.
> 
> One approach would be to hope that the return buffer's address was
> still there in the register it was passed in.  But there's no way to
> tell when you're wrong.  GDB will just print garbage, and the user
> will think their program is wrong.  Better to simply say, "I can't
> find this information reliably", and let the user, who knows their
> program, find another way to get the info --- setting a breakpoint on
> the return statement, or looking at where the caller put the
> structure.

Hmmmm.  I wonder if MIPS could ever be affected by this?  I don't think
the MIPS ABI specifies that $a0 remains live.  It looks as if the value
of $a0 is always returned in $v0 in such functions, though.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: tolerate unavailable struct return values

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Fri, Nov 30, 2001 at 03:49:52PM -0500, Jim Blandy wrote:
> >
> > Daniel Jacobowitz <drow@mvista.com> writes:
> > > On Thu, Nov 29, 2001 at 05:09:13PM -0500, Jim Blandy wrote:
> > > >
> > > > On some architectures, it's impossible for GDB to find structs
> > > > returned by value.  These shouldn't be failures.  Should they be
> > > > passes?
> > >
> > > Out of curiousity, which architectures?  And to be pedantic, I suspect
> > > that it might be "not always possible" rather than actually
> > > impossible.
> >
> > The one I have in mind is the S/390, although I'm pretty sure there
> > are others.  I've included the bug report I sent to the S/390 GCC
> > maintainers below.
> >
> > One approach would be to hope that the return buffer's address was
> > still there in the register it was passed in.  But there's no way to
> > tell when you're wrong.  GDB will just print garbage, and the user
> > will think their program is wrong.  Better to simply say, "I can't
> > find this information reliably", and let the user, who knows their
> > program, find another way to get the info --- setting a breakpoint on
> > the return statement, or looking at where the caller put the
> > structure.
> 
> Hmmmm.  I wonder if MIPS could ever be affected by this?  I don't think
> the MIPS ABI specifies that $a0 remains live.  It looks as if the value
> of $a0 is always returned in $v0 in such functions, though.

It's not an uncommon problem, and I imagine we get it wrong a lot of the time.

RFA: tolerate unavailable struct return values

[Jim Blandy]

On some architectures, it's impossible for GDB to find structs
returned by value.  These shouldn't be failures.  Should they be
passes?

2001-11-29  Jim Blandy  <jimb@redhat.com>

	If GDB says it can't find the struct the function returned, treat
	that as an expected failure.
	* gdb.base/structs.exp (call_struct_func): New function.
	(do_function_calls): Use call_struct_func to call the functions
	returning structs.

Index: gdb/testsuite/gdb.base/structs.exp
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.base/structs.exp,v
retrieving revision 1.17
diff -c -r1.17 structs.exp
*** gdb/testsuite/gdb.base/structs.exp	2001/08/09 18:02:02	1.17
--- gdb/testsuite/gdb.base/structs.exp	2001/11/29 17:46:25
***************
*** 54,59 ****
--- 54,85 ----
      continue
  }
  
+ 
+ # Call FUNC with no arguments, and expect to see the regexp RESULT in
+ # the output.  If we get back the error message "Function return value
+ # unknown", call that an expected failure; on some architectures, it's
+ # impossible to find structs returned by value reliably.
+ proc call_struct_func { func result } {
+     global gdb_prompt
+     
+     set command "p ${func}()"
+     send_gdb "${command}\n"
+     gdb_expect {
+         -re "$result\[\r\n\]+$gdb_prompt $" {
+             pass "$command"
+         }
+         -re "Function return value unknown.\[\r\n\]+$gdb_prompt $" {
+             xfail "$command"
+         }
+         -re "$gdb_prompt $" {
+             fail "$command"
+         }
+         timeout {
+             fail "$command (timeout)"
+         }
+     }
+ }
+ 
  # FIXME:  Before calling this proc, we should probably verify that
  # we can call inferior functions and get a valid integral value
  # returned.
***************
*** 67,85 ****
      global gdb_prompt
  
      # First, call the "fun" functions and examine the value they return.
!     gdb_test "p fun1()" " = {a = 49 '1'}"
!     gdb_test "p fun2()" " = {a = 97 'a', b = 98 'b'}"
!     gdb_test "p fun3()" " = {a = 65 'A', b = 66 'B', c = 67 'C'}"
!     gdb_test "p fun4()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4'}"
!     gdb_test "p fun5()" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e'}"
!     gdb_test "p fun6()" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F'}"
!     gdb_test "p fun7()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7'}"
!     gdb_test "p fun8()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8'}"
!     gdb_test "p fun9()" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i'}"
!     gdb_test "p fun10()" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J'}"
!     gdb_test "p fun11()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8', i = 57 '9', j = 65 'A', k = 66 'B'}"
!     gdb_test "p fun12()" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J', k = 75 'K', l = 76 'L'}"
!     gdb_test "p fun16()" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i', j = 106 'j', k = 107 'k', l = 108 'l', m = 109 'm', n = 110 'n', o = 111 'o', p = 112 'p'}"
  
      # Now call the Fun functions to set the L* variables.  This
      # tests that gdb properly passes structures to functions.
--- 93,111 ----
      global gdb_prompt
  
      # First, call the "fun" functions and examine the value they return.
!     call_struct_func "fun1" " = {a = 49 '1'}"
!     call_struct_func "fun2" " = {a = 97 'a', b = 98 'b'}"
!     call_struct_func "fun3" " = {a = 65 'A', b = 66 'B', c = 67 'C'}"
!     call_struct_func "fun4" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4'}"
!     call_struct_func "fun5" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e'}"
!     call_struct_func "fun6" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F'}"
!     call_struct_func "fun7" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7'}"
!     call_struct_func "fun8" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8'}"
!     call_struct_func "fun9" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i'}"
!     call_struct_func "fun10" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J'}"
!     call_struct_func "fun11" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8', i = 57 '9', j = 65 'A', k = 66 'B'}"
!     call_struct_func "fun12" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J', k = 75 'K', l = 76 'L'}"
!     call_struct_func "fun16" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i', j = 106 'j', k = 107 'k', l = 108 'l', m = 109 'm', n = 110 'n', o = 111 'o', p = 112 'p'}"
  
      # Now call the Fun functions to set the L* variables.  This
      # tests that gdb properly passes structures to functions.

Re: RFA: tolerate unavailable struct return values

[Michael Snyder]

Jim Blandy wrote:
> 
> On some architectures, it's impossible for GDB to find structs
> returned by value.  These shouldn't be failures.  Should they be
> passes?

I kinda like the idea of their being xfails.  The functionality
is not there, it's just not a surprise.


> 
> 2001-11-29  Jim Blandy  <jimb@redhat.com>
> 
>         If GDB says it can't find the struct the function returned, treat
>         that as an expected failure.
>         * gdb.base/structs.exp (call_struct_func): New function.
>         (do_function_calls): Use call_struct_func to call the functions
>         returning structs.
> 
> Index: gdb/testsuite/gdb.base/structs.exp
> ===================================================================
> RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.base/structs.exp,v
> retrieving revision 1.17
> diff -c -r1.17 structs.exp
> *** gdb/testsuite/gdb.base/structs.exp  2001/08/09 18:02:02     1.17
> --- gdb/testsuite/gdb.base/structs.exp  2001/11/29 17:46:25
> ***************
> *** 54,59 ****
> --- 54,85 ----
>       continue
>   }
> 
> +
> + # Call FUNC with no arguments, and expect to see the regexp RESULT in
> + # the output.  If we get back the error message "Function return value
> + # unknown", call that an expected failure; on some architectures, it's
> + # impossible to find structs returned by value reliably.
> + proc call_struct_func { func result } {
> +     global gdb_prompt
> +
> +     set command "p ${func}()"
> +     send_gdb "${command}\n"
> +     gdb_expect {
> +         -re "$result\[\r\n\]+$gdb_prompt $" {
> +             pass "$command"
> +         }
> +         -re "Function return value unknown.\[\r\n\]+$gdb_prompt $" {
> +             xfail "$command"
> +         }
> +         -re "$gdb_prompt $" {
> +             fail "$command"
> +         }
> +         timeout {
> +             fail "$command (timeout)"
> +         }
> +     }
> + }
> +
>   # FIXME:  Before calling this proc, we should probably verify that
>   # we can call inferior functions and get a valid integral value
>   # returned.
> ***************
> *** 67,85 ****
>       global gdb_prompt
> 
>       # First, call the "fun" functions and examine the value they return.
> !     gdb_test "p fun1()" " = {a = 49 '1'}"
> !     gdb_test "p fun2()" " = {a = 97 'a', b = 98 'b'}"
> !     gdb_test "p fun3()" " = {a = 65 'A', b = 66 'B', c = 67 'C'}"
> !     gdb_test "p fun4()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4'}"
> !     gdb_test "p fun5()" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e'}"
> !     gdb_test "p fun6()" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F'}"
> !     gdb_test "p fun7()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7'}"
> !     gdb_test "p fun8()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8'}"
> !     gdb_test "p fun9()" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i'}"
> !     gdb_test "p fun10()" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J'}"
> !     gdb_test "p fun11()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8', i = 57 '9', j = 65 'A', k = 66 'B'}"
> !     gdb_test "p fun12()" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J', k = 75 'K', l = 76 'L'}"
> !     gdb_test "p fun16()" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i', j = 106 'j', k = 107 'k', l = 108 'l', m = 109 'm', n = 110 'n', o = 111 'o', p = 112 'p'}"
> 
>       # Now call the Fun functions to set the L* variables.  This
>       # tests that gdb properly passes structures to functions.
> --- 93,111 ----
>       global gdb_prompt
> 
>       # First, call the "fun" functions and examine the value they return.
> !     call_struct_func "fun1" " = {a = 49 '1'}"
> !     call_struct_func "fun2" " = {a = 97 'a', b = 98 'b'}"
> !     call_struct_func "fun3" " = {a = 65 'A', b = 66 'B', c = 67 'C'}"
> !     call_struct_func "fun4" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4'}"
> !     call_struct_func "fun5" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e'}"
> !     call_struct_func "fun6" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F'}"
> !     call_struct_func "fun7" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7'}"
> !     call_struct_func "fun8" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8'}"
> !     call_struct_func "fun9" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i'}"
> !     call_struct_func "fun10" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J'}"
> !     call_struct_func "fun11" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8', i = 57 '9', j = 65 'A', k = 66 'B'}"
> !     call_struct_func "fun12" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J', k = 75 'K', l = 76 'L'}"
> !     call_struct_func "fun16" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i', j = 106 'j', k = 107 'k', l = 108 'l', m = 109 'm', n = 110 'n', o = 111 'o', p = 112 'p'}"
> 
>       # Now call the Fun functions to set the L* variables.  This
>       # tests that gdb properly passes structures to functions.

Re: RFA: tolerate unavailable struct return values

[Daniel Jacobowitz]

On Thu, Nov 29, 2001 at 05:09:13PM -0500, Jim Blandy wrote:
> 
> On some architectures, it's impossible for GDB to find structs
> returned by value.  These shouldn't be failures.  Should they be
> passes?

Out of curiousity, which architectures?  And to be pedantic, I suspect
that it might be "not always possible" rather than actually impossible.

Nit-picking aside, I agree with Michael.  This is the most appropriate
use for XFAIL, as opposed to some of the other things we use it for :)

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: tolerate unavailable struct return values

[Jim Blandy]

Tom Tromey <tromey@redhat.com> writes:
> Jim> On some architectures, it's impossible for GDB to find structs
> Jim> returned by value.  These shouldn't be failures.  Should they be
> Jim> passes?
> 
> Dejagnu also knows about "UNTESTED" and "UNSUPPORTED".
> See (dejagnu)Posix

That sounds right.  Revised patch:

2001-11-29  Jim Blandy  <jimb@redhat.com>

	If GDB says it can't find the struct the function returned, report
	those tests as `unsupported'.
	* gdb.base/structs.exp (call_struct_func): New function.
	(do_function_calls): Use call_struct_func to call the functions
	returning structs.

Index: gdb/testsuite/gdb.base/structs.exp
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.base/structs.exp,v
retrieving revision 1.17
diff -c -r1.17 structs.exp
*** gdb/testsuite/gdb.base/structs.exp	2001/08/09 18:02:02	1.17
--- gdb/testsuite/gdb.base/structs.exp	2001/11/30 06:37:45
***************
*** 54,59 ****
--- 54,85 ----
      continue
  }
  
+ 
+ # Call FUNC with no arguments, and expect to see the regexp RESULT in
+ # the output.  If we get back the error message "Function return value
+ # unknown", call that an expected failure; on some architectures, it's
+ # impossible to find structs returned by value reliably.
+ proc call_struct_func { func result } {
+     global gdb_prompt
+     
+     set command "p ${func}()"
+     send_gdb "${command}\n"
+     gdb_expect {
+         -re "$result\[\r\n\]+$gdb_prompt $" {
+             pass "$command"
+         }
+         -re "Function return value unknown.\[\r\n\]+$gdb_prompt $" {
+             unsupported "$command"
+         }
+         -re "$gdb_prompt $" {
+             fail "$command"
+         }
+         timeout {
+             fail "$command (timeout)"
+         }
+     }
+ }
+ 
  # FIXME:  Before calling this proc, we should probably verify that
  # we can call inferior functions and get a valid integral value
  # returned.
***************
*** 67,85 ****
      global gdb_prompt
  
      # First, call the "fun" functions and examine the value they return.
!     gdb_test "p fun1()" " = {a = 49 '1'}"
!     gdb_test "p fun2()" " = {a = 97 'a', b = 98 'b'}"
!     gdb_test "p fun3()" " = {a = 65 'A', b = 66 'B', c = 67 'C'}"
!     gdb_test "p fun4()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4'}"
!     gdb_test "p fun5()" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e'}"
!     gdb_test "p fun6()" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F'}"
!     gdb_test "p fun7()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7'}"
!     gdb_test "p fun8()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8'}"
!     gdb_test "p fun9()" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i'}"
!     gdb_test "p fun10()" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J'}"
!     gdb_test "p fun11()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8', i = 57 '9', j = 65 'A', k = 66 'B'}"
!     gdb_test "p fun12()" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J', k = 75 'K', l = 76 'L'}"
!     gdb_test "p fun16()" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i', j = 106 'j', k = 107 'k', l = 108 'l', m = 109 'm', n = 110 'n', o = 111 'o', p = 112 'p'}"
  
      # Now call the Fun functions to set the L* variables.  This
      # tests that gdb properly passes structures to functions.
--- 93,111 ----
      global gdb_prompt
  
      # First, call the "fun" functions and examine the value they return.
!     call_struct_func "fun1" " = {a = 49 '1'}"
!     call_struct_func "fun2" " = {a = 97 'a', b = 98 'b'}"
!     call_struct_func "fun3" " = {a = 65 'A', b = 66 'B', c = 67 'C'}"
!     call_struct_func "fun4" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4'}"
!     call_struct_func "fun5" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e'}"
!     call_struct_func "fun6" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F'}"
!     call_struct_func "fun7" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7'}"
!     call_struct_func "fun8" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8'}"
!     call_struct_func "fun9" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i'}"
!     call_struct_func "fun10" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J'}"
!     call_struct_func "fun11" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8', i = 57 '9', j = 65 'A', k = 66 'B'}"
!     call_struct_func "fun12" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J', k = 75 'K', l = 76 'L'}"
!     call_struct_func "fun16" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i', j = 106 'j', k = 107 'k', l = 108 'l', m = 109 'm', n = 110 'n', o = 111 'o', p = 112 'p'}"
  
      # Now call the Fun functions to set the L* variables.  This
      # tests that gdb properly passes structures to functions.

Re: RFA: tolerate unavailable struct return values

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> On Thu, Nov 29, 2001 at 05:09:13PM -0500, Jim Blandy wrote:
> > 
> > On some architectures, it's impossible for GDB to find structs
> > returned by value.  These shouldn't be failures.  Should they be
> > passes?
> 
> Out of curiousity, which architectures?  And to be pedantic, I suspect
> that it might be "not always possible" rather than actually
> impossible.

The one I have in mind is the S/390, although I'm pretty sure there
are others.  I've included the bug report I sent to the S/390 GCC
maintainers below.

One approach would be to hope that the return buffer's address was
still there in the register it was passed in.  But there's no way to
tell when you're wrong.  GDB will just print garbage, and the user
will think their program is wrong.  Better to simply say, "I can't
find this information reliably", and let the user, who knows their
program, find another way to get the info --- setting a breakpoint on
the return statement, or looking at where the caller put the
structure.


------- Start of forwarded message -------
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Hartmut Penner <hpenner@de.ibm.com>,
	Ulrich Weigand <uweigand@de.ibm.com>
Cc: Chris Moller <cmoller@redhat.com>,
	Matt Hiller <hiller@cygnus.com>
Subject: GDB unable to find structs returned by value using S/390 ABI 
Message-Id: <20011129190712.6AA5D5E9DB@zwingli.cygnus.com>
Date: Thu, 29 Nov 2001 14:07:12 -0500 (EST)


Given the way the S/390 Linux ABI specifies functions should return
structures by value, it is sometimes impossible for GDB to find
functions' return values.  There is a simple fix for this which is
backwards binary compatible with existing code; I don't think it will
have much impact on performance.

According to the ABI, structures which are one, two, four, or eight
bytes long must be returned by value in registers r2 and r3.  These
structures pose no problem for GDB.  However, the ABI specifies that
all other structures should be written to a buffer allocated by the
caller, whose address is passed to the callee as an "invisible" first
argument, in r2.  GDB is unable to find structs returned this way.

Suppose the user is running their program under GDB, and stops
execution in the middle of a function which will return a structure by
value.  The user then types the 'finish' command, which runs the
current function call to completion, and prints the value it returns.

By the time the function has returned to its caller, it will have
stored the returned struct in the caller's buffer.  Unfortunately, GDB
has no way at this point to find out where this buffer is.  The caller
passed it to the callee in r2, but the callee is free to do whatever
it pleases with that address; r2's value is unspecified upon return.

I suggest that we amend the ABI to require the callee to return the
address of the buffer holding the returned struct in r2.  This will
allow GDB to reliably find the buffer.  Since the pointer to the
buffer is live until the return value has been computed anyway, this
requirement shouldn't significantly increase register pressure in the
callee.

------- End of forwarded message -------

Re: RFA: tolerate unavailable struct return values

[Daniel Jacobowitz]

On Fri, Nov 30, 2001 at 03:49:52PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> > On Thu, Nov 29, 2001 at 05:09:13PM -0500, Jim Blandy wrote:
> > > 
> > > On some architectures, it's impossible for GDB to find structs
> > > returned by value.  These shouldn't be failures.  Should they be
> > > passes?
> > 
> > Out of curiousity, which architectures?  And to be pedantic, I suspect
> > that it might be "not always possible" rather than actually
> > impossible.
> 
> The one I have in mind is the S/390, although I'm pretty sure there
> are others.  I've included the bug report I sent to the S/390 GCC
> maintainers below.
> 
> One approach would be to hope that the return buffer's address was
> still there in the register it was passed in.  But there's no way to
> tell when you're wrong.  GDB will just print garbage, and the user
> will think their program is wrong.  Better to simply say, "I can't
> find this information reliably", and let the user, who knows their
> program, find another way to get the info --- setting a breakpoint on
> the return statement, or looking at where the caller put the
> structure.

Hmmmm.  I wonder if MIPS could ever be affected by this?  I don't think
the MIPS ABI specifies that $a0 remains live.  It looks as if the value
of $a0 is always returned in $v0 in such functions, though.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: tolerate unavailable struct return values

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Fri, Nov 30, 2001 at 03:49:52PM -0500, Jim Blandy wrote:
> >
> > Daniel Jacobowitz <drow@mvista.com> writes:
> > > On Thu, Nov 29, 2001 at 05:09:13PM -0500, Jim Blandy wrote:
> > > >
> > > > On some architectures, it's impossible for GDB to find structs
> > > > returned by value.  These shouldn't be failures.  Should they be
> > > > passes?
> > >
> > > Out of curiousity, which architectures?  And to be pedantic, I suspect
> > > that it might be "not always possible" rather than actually
> > > impossible.
> >
> > The one I have in mind is the S/390, although I'm pretty sure there
> > are others.  I've included the bug report I sent to the S/390 GCC
> > maintainers below.
> >
> > One approach would be to hope that the return buffer's address was
> > still there in the register it was passed in.  But there's no way to
> > tell when you're wrong.  GDB will just print garbage, and the user
> > will think their program is wrong.  Better to simply say, "I can't
> > find this information reliably", and let the user, who knows their
> > program, find another way to get the info --- setting a breakpoint on
> > the return statement, or looking at where the caller put the
> > structure.
> 
> Hmmmm.  I wonder if MIPS could ever be affected by this?  I don't think
> the MIPS ABI specifies that $a0 remains live.  It looks as if the value
> of $a0 is always returned in $v0 in such functions, though.

It's not an uncommon problem, and I imagine we get it wrong a lot of the time.

Re: RFA: tolerate unavailable struct return values

[Elena Zannoni]

Michael Snyder writes:
 > Daniel Jacobowitz wrote:
 > > 
 > > On Fri, Nov 30, 2001 at 03:49:52PM -0500, Jim Blandy wrote:
 > > >
 > > > Daniel Jacobowitz <drow@mvista.com> writes:
 > > > > On Thu, Nov 29, 2001 at 05:09:13PM -0500, Jim Blandy wrote:
 > > > > >
 > > > > > On some architectures, it's impossible for GDB to find structs
 > > > > > returned by value.  These shouldn't be failures.  Should they be
 > > > > > passes?
 > > > >
 > > > > Out of curiousity, which architectures?  And to be pedantic, I suspect
 > > > > that it might be "not always possible" rather than actually
 > > > > impossible.
 > > >
 > > > The one I have in mind is the S/390, although I'm pretty sure there
 > > > are others.  I've included the bug report I sent to the S/390 GCC
 > > > maintainers below.
 > > >
 > > > One approach would be to hope that the return buffer's address was
 > > > still there in the register it was passed in.  But there's no way to
 > > > tell when you're wrong.  GDB will just print garbage, and the user
 > > > will think their program is wrong.  Better to simply say, "I can't
 > > > find this information reliably", and let the user, who knows their
 > > > program, find another way to get the info --- setting a breakpoint on
 > > > the return statement, or looking at where the caller put the
 > > > structure.
 > > 
 > > Hmmmm.  I wonder if MIPS could ever be affected by this?  I don't think
 > > the MIPS ABI specifies that $a0 remains live.  It looks as if the value
 > > of $a0 is always returned in $v0 in such functions, though.
 > 
 > It's not an uncommon problem, and I imagine we get it wrong a lot of the time.

Have you looked at the macro VALUE_RETURNED_FROM_STACK ? I defined that
long time ago for hppa. It looks like the rs6000-tdep.c tries to deal
with the same problem as well.

Maybe we should clean up that code, which came in as part of the HP
merge :-(.

Elena

Re: RFA: tolerate unavailable struct return values

[Jim Blandy]

Elena Zannoni <ezannoni@cygnus.com> writes:
> Michael Snyder writes:
>  > Daniel Jacobowitz wrote:
>  > > On Fri, Nov 30, 2001 at 03:49:52PM -0500, Jim Blandy wrote:
>  > > > Daniel Jacobowitz <drow@mvista.com> writes:
>  > > > > On Thu, Nov 29, 2001 at 05:09:13PM -0500, Jim Blandy wrote:
>  > > > > >
>  > > > > > On some architectures, it's impossible for GDB to find structs
>  > > > > > returned by value.  These shouldn't be failures.  Should they be
>  > > > > > passes?
>  > > > >
>  > > > > Out of curiousity, which architectures?  And to be pedantic, I suspect
>  > > > > that it might be "not always possible" rather than actually
>  > > > > impossible.
>  > > >
>  > > > The one I have in mind is the S/390, although I'm pretty sure there
>  > > > are others.  I've included the bug report I sent to the S/390 GCC
>  > > > maintainers below.
>  > > >
>  > > > One approach would be to hope that the return buffer's address was
>  > > > still there in the register it was passed in.  But there's no way to
>  > > > tell when you're wrong.  GDB will just print garbage, and the user
>  > > > will think their program is wrong.  Better to simply say, "I can't
>  > > > find this information reliably", and let the user, who knows their
>  > > > program, find another way to get the info --- setting a breakpoint on
>  > > > the return statement, or looking at where the caller put the
>  > > > structure.
>  > > 
>  > > Hmmmm.  I wonder if MIPS could ever be affected by this?  I don't think
>  > > the MIPS ABI specifies that $a0 remains live.  It looks as if the value
>  > > of $a0 is always returned in $v0 in such functions, though.
>  > 
>  > It's not an uncommon problem, and I imagine we get it wrong a lot of the time.
> 
> Have you looked at the macro VALUE_RETURNED_FROM_STACK ? I defined that
> long time ago for hppa. It looks like the rs6000-tdep.c tries to deal
> with the same problem as well.
> 
> Maybe we should clean up that code, which came in as part of the HP
> merge :-(.

Looking at the following code in infcmd.c:

      /* We cannot determine the contents of the structure because
	 it is on the stack, and we don't know where, since we did not
	 initiate the call, as opposed to the call_function_by_hand case */
#ifdef VALUE_RETURNED_FROM_STACK
      value = 0;
#ifdef UI_OUT
      ui_out_text (uiout, "Value returned has type: ");
      ui_out_field_string (uiout, "return-type", TYPE_NAME (value_type));
      ui_out_text (uiout, ".");
      ui_out_text (uiout, " Cannot determine contents\n");
#else /* UI_OUT */
      printf_filtered ("Value returned has type: %s.", TYPE_NAME (value_type));
      printf_filtered (" Cannot determine contents\n");
#endif /* UI_OUT */
#else
      value = value_being_returned (value_type, stop_registers, structure_return);

and then at the following code in valops.c:

#ifdef VALUE_RETURNED_FROM_STACK
    if (struct_return)
      return (value_ptr) VALUE_RETURNED_FROM_STACK (value_type, struct_addr);
#endif

the stuff in infcmd.c looks backwards to me.  Wasn't the intention to
fall back to printing the type when VALUE_RETURNED_FROM_STACK is *not*
defined?

TYPE_NAME is just the structure tag; don't we want to print the
`struct' or `union' there?  The `type_print' function takes care of
that.

Frankly, I don't even think it's that useful to print the type.  The
user knows what function was called, and can use `ptype' or `whatis'
if they want to know the type.

Re: RFA: tolerate unavailable struct return values

[Elena Zannoni]

Jim Blandy writes:
 > > Have you looked at the macro VALUE_RETURNED_FROM_STACK ? I defined that
 > > long time ago for hppa. It looks like the rs6000-tdep.c tries to deal
 > > with the same problem as well.
 > > 
 > > Maybe we should clean up that code, which came in as part of the HP
 > > merge :-(.
 > 
 > Looking at the following code in infcmd.c:
 > 
 >       /* We cannot determine the contents of the structure because
 > 	 it is on the stack, and we don't know where, since we did not
 > 	 initiate the call, as opposed to the call_function_by_hand case */
 > #ifdef VALUE_RETURNED_FROM_STACK
 >       value = 0;
 > #ifdef UI_OUT
 >       ui_out_text (uiout, "Value returned has type: ");
 >       ui_out_field_string (uiout, "return-type", TYPE_NAME (value_type));
 >       ui_out_text (uiout, ".");
 >       ui_out_text (uiout, " Cannot determine contents\n");
 > #else /* UI_OUT */
 >       printf_filtered ("Value returned has type: %s.", TYPE_NAME (value_type));
 >       printf_filtered (" Cannot determine contents\n");
 > #endif /* UI_OUT */
 > #else
 >       value = value_being_returned (value_type, stop_registers, structure_return);
 > 
 > and then at the following code in valops.c:
 > 
 > #ifdef VALUE_RETURNED_FROM_STACK
 >     if (struct_return)
 >       return (value_ptr) VALUE_RETURNED_FROM_STACK (value_type, struct_addr);
 > #endif
 > 
 > the stuff in infcmd.c looks backwards to me.  Wasn't the intention to
 > fall back to printing the type when VALUE_RETURNED_FROM_STACK is *not*
 > defined?

Not all the times, no, it was meant to be only used by hpux. I didn't
have any way to test other targets when I wrote that, so I didn't want
to touch anything else (whether or not such other targets could
display the structre correctly). It should definitely be cleaned up.

 > 
 > TYPE_NAME is just the structure tag; don't we want to print the
 > `struct' or `union' there?  The `type_print' function takes care of
 > that.
 > 

Probably.

 > Frankly, I don't even think it's that useful to print the type.  The
 > user knows what function was called, and can use `ptype' or `whatis'
 > if they want to know the type.

I wanted it to be more informative, and remind the user of what the
result would have been, w/o them having to do an extra step.

Elena

Re: RFA: tolerate unavailable struct return values

[Jim Blandy]

Err, this time for sure!  (Doc was wrong in last patch.)

2001-11-29  Jim Blandy  <jimb@redhat.com>

	If GDB says it can't find the struct the function returned, report
	those tests as `unsupported'.
	* gdb.base/structs.exp (call_struct_func): New function.
	(do_function_calls): Use call_struct_func to call the functions
	returning structs.

Index: gdb/testsuite/gdb.base/structs.exp
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.base/structs.exp,v
retrieving revision 1.17
diff -c -r1.17 structs.exp
*** gdb/testsuite/gdb.base/structs.exp	2001/08/09 18:02:02	1.17
--- gdb/testsuite/gdb.base/structs.exp	2001/11/30 06:45:42
***************
*** 54,59 ****
--- 54,85 ----
      continue
  }
  
+ 
+ # Call FUNC with no arguments, and expect to see the regexp RESULT in
+ # the output.  If we get back the error message "Function return value
+ # unknown", call that an unsupported test; on some architectures, it's
+ # impossible to find structs returned by value reliably.
+ proc call_struct_func { func result } {
+     global gdb_prompt
+     
+     set command "p ${func}()"
+     send_gdb "${command}\n"
+     gdb_expect {
+         -re "$result\[\r\n\]+$gdb_prompt $" {
+             pass "$command"
+         }
+         -re "Function return value unknown.\[\r\n\]+$gdb_prompt $" {
+             unsupported "$command"
+         }
+         -re "$gdb_prompt $" {
+             fail "$command"
+         }
+         timeout {
+             fail "$command (timeout)"
+         }
+     }
+ }
+ 
  # FIXME:  Before calling this proc, we should probably verify that
  # we can call inferior functions and get a valid integral value
  # returned.
***************
*** 67,85 ****
      global gdb_prompt
  
      # First, call the "fun" functions and examine the value they return.
!     gdb_test "p fun1()" " = {a = 49 '1'}"
!     gdb_test "p fun2()" " = {a = 97 'a', b = 98 'b'}"
!     gdb_test "p fun3()" " = {a = 65 'A', b = 66 'B', c = 67 'C'}"
!     gdb_test "p fun4()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4'}"
!     gdb_test "p fun5()" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e'}"
!     gdb_test "p fun6()" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F'}"
!     gdb_test "p fun7()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7'}"
!     gdb_test "p fun8()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8'}"
!     gdb_test "p fun9()" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i'}"
!     gdb_test "p fun10()" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J'}"
!     gdb_test "p fun11()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8', i = 57 '9', j = 65 'A', k = 66 'B'}"
!     gdb_test "p fun12()" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J', k = 75 'K', l = 76 'L'}"
!     gdb_test "p fun16()" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i', j = 106 'j', k = 107 'k', l = 108 'l', m = 109 'm', n = 110 'n', o = 111 'o', p = 112 'p'}"
  
      # Now call the Fun functions to set the L* variables.  This
      # tests that gdb properly passes structures to functions.
--- 93,111 ----
      global gdb_prompt
  
      # First, call the "fun" functions and examine the value they return.
!     call_struct_func "fun1" " = {a = 49 '1'}"
!     call_struct_func "fun2" " = {a = 97 'a', b = 98 'b'}"
!     call_struct_func "fun3" " = {a = 65 'A', b = 66 'B', c = 67 'C'}"
!     call_struct_func "fun4" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4'}"
!     call_struct_func "fun5" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e'}"
!     call_struct_func "fun6" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F'}"
!     call_struct_func "fun7" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7'}"
!     call_struct_func "fun8" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8'}"
!     call_struct_func "fun9" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i'}"
!     call_struct_func "fun10" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J'}"
!     call_struct_func "fun11" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8', i = 57 '9', j = 65 'A', k = 66 'B'}"
!     call_struct_func "fun12" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J', k = 75 'K', l = 76 'L'}"
!     call_struct_func "fun16" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i', j = 106 'j', k = 107 'k', l = 108 'l', m = 109 'm', n = 110 'n', o = 111 'o', p = 112 'p'}"
  
      # Now call the Fun functions to set the L* variables.  This
      # tests that gdb properly passes structures to functions.

Re: RFA: tolerate unavailable struct return values

[Jim Blandy]

Err, this time for sure!  (Doc was wrong in last patch.)

2001-11-29  Jim Blandy  <jimb@redhat.com>

	If GDB says it can't find the struct the function returned, report
	those tests as `unsupported'.
	* gdb.base/structs.exp (call_struct_func): New function.
	(do_function_calls): Use call_struct_func to call the functions
	returning structs.

Index: gdb/testsuite/gdb.base/structs.exp
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.base/structs.exp,v
retrieving revision 1.17
diff -c -r1.17 structs.exp
*** gdb/testsuite/gdb.base/structs.exp	2001/08/09 18:02:02	1.17
--- gdb/testsuite/gdb.base/structs.exp	2001/11/30 06:45:42
***************
*** 54,59 ****
--- 54,85 ----
      continue
  }
  
+ 
+ # Call FUNC with no arguments, and expect to see the regexp RESULT in
+ # the output.  If we get back the error message "Function return value
+ # unknown", call that an unsupported test; on some architectures, it's
+ # impossible to find structs returned by value reliably.
+ proc call_struct_func { func result } {
+     global gdb_prompt
+     
+     set command "p ${func}()"
+     send_gdb "${command}\n"
+     gdb_expect {
+         -re "$result\[\r\n\]+$gdb_prompt $" {
+             pass "$command"
+         }
+         -re "Function return value unknown.\[\r\n\]+$gdb_prompt $" {
+             unsupported "$command"
+         }
+         -re "$gdb_prompt $" {
+             fail "$command"
+         }
+         timeout {
+             fail "$command (timeout)"
+         }
+     }
+ }
+ 
  # FIXME:  Before calling this proc, we should probably verify that
  # we can call inferior functions and get a valid integral value
  # returned.
***************
*** 67,85 ****
      global gdb_prompt
  
      # First, call the "fun" functions and examine the value they return.
!     gdb_test "p fun1()" " = {a = 49 '1'}"
!     gdb_test "p fun2()" " = {a = 97 'a', b = 98 'b'}"
!     gdb_test "p fun3()" " = {a = 65 'A', b = 66 'B', c = 67 'C'}"
!     gdb_test "p fun4()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4'}"
!     gdb_test "p fun5()" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e'}"
!     gdb_test "p fun6()" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F'}"
!     gdb_test "p fun7()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7'}"
!     gdb_test "p fun8()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8'}"
!     gdb_test "p fun9()" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i'}"
!     gdb_test "p fun10()" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J'}"
!     gdb_test "p fun11()" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8', i = 57 '9', j = 65 'A', k = 66 'B'}"
!     gdb_test "p fun12()" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J', k = 75 'K', l = 76 'L'}"
!     gdb_test "p fun16()" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i', j = 106 'j', k = 107 'k', l = 108 'l', m = 109 'm', n = 110 'n', o = 111 'o', p = 112 'p'}"
  
      # Now call the Fun functions to set the L* variables.  This
      # tests that gdb properly passes structures to functions.
--- 93,111 ----
      global gdb_prompt
  
      # First, call the "fun" functions and examine the value they return.
!     call_struct_func "fun1" " = {a = 49 '1'}"
!     call_struct_func "fun2" " = {a = 97 'a', b = 98 'b'}"
!     call_struct_func "fun3" " = {a = 65 'A', b = 66 'B', c = 67 'C'}"
!     call_struct_func "fun4" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4'}"
!     call_struct_func "fun5" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e'}"
!     call_struct_func "fun6" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F'}"
!     call_struct_func "fun7" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7'}"
!     call_struct_func "fun8" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8'}"
!     call_struct_func "fun9" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i'}"
!     call_struct_func "fun10" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J'}"
!     call_struct_func "fun11" " = {a = 49 '1', b = 50 '2', c = 51 '3', d = 52 '4', e = 53 '5', f = 54 '6', g = 55 '7', h = 56 '8', i = 57 '9', j = 65 'A', k = 66 'B'}"
!     call_struct_func "fun12" " = {a = 65 'A', b = 66 'B', c = 67 'C', d = 68 'D', e = 69 'E', f = 70 'F', g = 71 'G', h = 72 'H', i = 73 'I', j = 74 'J', k = 75 'K', l = 76 'L'}"
!     call_struct_func "fun16" " = {a = 97 'a', b = 98 'b', c = 99 'c', d = 100 'd', e = 101 'e', f = 102 'f', g = 103 'g', h = 104 'h', i = 105 'i', j = 106 'j', k = 107 'k', l = 108 'l', m = 109 'm', n = 110 'n', o = 111 'o', p = 112 'p'}"
  
      # Now call the Fun functions to set the L* variables.  This
      # tests that gdb properly passes structures to functions.