"optimized out" on gdb.base/gdb1090.exp

"optimized out" on gdb.base/gdb1090.exp

[Edjunior Barbosa Machado]

Hi,

running the testcase gdb.base/gdb1090.exp on ppc64 using gcc 4.3.4, noticed an unexpected error in the second test:

#1  0x00000000100005dc in foo () at ../../../gdb.git/gdb/testsuite/gdb.base/gdb1090.c:39^M
39        marker (s24);^M
(gdb) PASS: gdb.base/gdb1090.exp: up from marker
print s24^M
$1 = <optimized out>^M
(gdb) FAIL: gdb.base/gdb1090.exp: print s24

According to readelf output, s24 uses r9, which is a volatile register.
However, the content is properly printed when using gcc 4.4.5 (var s24 goes to r30, which is not volatile on power)

Just wondering, can we consider this last test as untested (or even pass) when print returns "optimized out", since it does not print garbage (which was the original issue from gdb/1090)?

Thanks,
-- 
Edjunior

Re: "optimized out" on gdb.base/gdb1090.exp

[Yao Qi]

On 04/12/2011 09:16 AM, Edjunior Barbosa Machado wrote:
> Hi,
> 
> running the testcase gdb.base/gdb1090.exp on ppc64 using gcc 4.3.4,
> noticed an unexpected error in the second test:
> 
> #1  0x00000000100005dc in foo () at
> ../../../gdb.git/gdb/testsuite/gdb.base/gdb1090.c:39^M
> 39        marker (s24);^M
> (gdb) PASS: gdb.base/gdb1090.exp: up from marker
> print s24^M
> $1 = <optimized out>^M
> (gdb) FAIL: gdb.base/gdb1090.exp: print s24
> 
> According to readelf output, s24 uses r9, which is a volatile register.
> However, the content is properly printed when using gcc 4.4.5 (var s24
> goes to r30, which is not volatile on power)
> 
> Just wondering, can we consider this last test as untested (or even
> pass) when print returns "optimized out", since it does not print
> garbage (which was the original issue from gdb/1090)?
> 

If we set breakpoint directly on a certain line of main(), and check the
value of `s24' in main().  Can we get the value of `s24'?  If we can, we
may modify test case a little bit, instead of marking this case as
untested (or even pass).

-- 
Yao (齐尧)

Re: "optimized out" on gdb.base/gdb1090.exp

[Edjunior Barbosa Machado]

On 04/11/2011 11:20 PM, Yao Qi wrote:
> On 04/12/2011 09:16 AM, Edjunior Barbosa Machado wrote:
>> Hi,
>>
>> running the testcase gdb.base/gdb1090.exp on ppc64 using gcc 4.3.4,
>> noticed an unexpected error in the second test:
>>
>> #1  0x00000000100005dc in foo () at
>> ../../../gdb.git/gdb/testsuite/gdb.base/gdb1090.c:39^M
>> 39        marker (s24);^M
>> (gdb) PASS: gdb.base/gdb1090.exp: up from marker
>> print s24^M
>> $1 =<optimized out>^M
>> (gdb) FAIL: gdb.base/gdb1090.exp: print s24
>>
>> According to readelf output, s24 uses r9, which is a volatile register.
>> However, the content is properly printed when using gcc 4.4.5 (var s24
>> goes to r30, which is not volatile on power)
>>
>> Just wondering, can we consider this last test as untested (or even
>> pass) when print returns "optimized out", since it does not print
>> garbage (which was the original issue from gdb/1090)?
>>
>
> If we set breakpoint directly on a certain line of main(), and check the
> value of `s24' in main().  Can we get the value of `s24'?  If we can, we
> may modify test case a little bit, instead of marking this case as
> untested (or even pass).
>

It works fine if I set a breakpoint in the end of foo() (which is the function where 's24' is declared).
My only concern is if this check in the same frame will not affect the main purpose of the testcase. If there is no problem with this, please consider the patch below.

Thanks,
-- 
Edjunior

2011-04-12  Edjunior Machado  <emachado@br.ibm.com>

	* testsuite/gdb.base/gdb1090.exp: change breakpoint location to	read the
	content of 's24' correctly (avoiding "optimized out").
	* testsuite/gdb.base/gdb1090.c: add comment in order to set breakpoint.

diff --git a/gdb/testsuite/gdb.base/gdb1090.c b/gdb/testsuite/gdb.base/gdb1090.c
index 22f2cec..72ebd2e 100644
--- a/gdb/testsuite/gdb.base/gdb1090.c
+++ b/gdb/testsuite/gdb.base/gdb1090.c
@@ -37,7 +37,7 @@ void foo ()
    s24.field_0 = 1170;
    s24.field_1 = 64701;
    marker (s24);
-  return;
+  return; /* break-here */
  }
  
  int main ()
diff --git a/gdb/testsuite/gdb.base/gdb1090.exp b/gdb/testsuite/gdb.base/gdb1090.exp
index a15fd04..0ff5c73 100644
--- a/gdb/testsuite/gdb.base/gdb1090.exp
+++ b/gdb/testsuite/gdb.base/gdb1090.exp
@@ -40,12 +40,9 @@ gdb_start
  gdb_reinitialize_dir $srcdir/$subdir
  gdb_load ${binfile}
  
-if ![runto marker] then {
-    perror "couldn't run to breakpoint"
-    continue
-}
-gdb_test "up" ".*foo.*" "up from marker"
+gdb_breakpoint [gdb_get_line_number "break-here"]
  
+gdb_run_cmd
  gdb_test_multiple "print s24" "print s24" {
      -re "\\\$\[0-9\]* = \\{field_0 = 1170, field_1 = 64701\\}\r\n$gdb_prompt $" {
  	pass "print s24"

Re: "optimized out" on gdb.base/gdb1090.exp

[Jan Kratochvil]

On Tue, 12 Apr 2011 15:44:29 +0200, Edjunior Barbosa Machado wrote:
> My only concern is if this check in the same frame will not affect the main
> purpose of the testcase.

One should find the fix, I do not see it obvious which one it is.


> --- a/gdb/testsuite/gdb.base/gdb1090.exp
> +++ b/gdb/testsuite/gdb.base/gdb1090.exp
> @@ -40,12 +40,9 @@ gdb_start
>  gdb_reinitialize_dir $srcdir/$subdir
>  gdb_load ${binfile}
> -if ![runto marker] then {
> -    perror "couldn't run to breakpoint"
> -    continue
> -}
> -gdb_test "up" ".*foo.*" "up from marker"
> +gdb_breakpoint [gdb_get_line_number "break-here"]
> +gdb_run_cmd

gdb_run_cmd produces output which is not caught anywhere here.  This will
result in testcase races.

BTW runto expects a function name, not file:line notation.

This is why the pair
	gdb_breakpoint [gdb_get_line_number "break-here"]
	gdb_continue_to_breakpoint "break-here" ".* break-here .*"

is popular.


>  gdb_test_multiple "print s24" "print s24" {
>      -re "\\\$\[0-9\]* = \\{field_0 = 1170, field_1 = 64701\\}\r\n$gdb_prompt $" {
>  	pass "print s24"


Thanks,
Jan