[PATCH] Powerpc, fix vla-optimized-out.exp test

[PATCH] Powerpc, fix vla-optimized-out.exp test

[Carl Love]

GDB maintainers:

The vla-optimized-out.exp test has a check to print the size of
variable a.  The test expects the size to be available even though the
use of the variable has been optimized out.  This is true on Intel. 
However, on Powerpc both the use and the size of the variable are
optimized out.

This patch adds to the test to check for the size or optimized out. The
change fixes the test failure on Powerpc.

The patch has been tested on a Power 10 system and on and Intel 64-bit
system.  No regressions were seen.

Please let me know if this patch is acceptable for gdb mainline. 
Thanks.

                    Carl Love

------------------------------------------
Powerpc, fix vla-optimized-out.exp test

The size of the variable vla is not optimized out on Intel inspite of the
use of the variable use being optimized out.

On Powerpc, the use of vla and the size of vla are both optimized out.

The output on Powerpc is:

p sizeof (a)
$2 = <optimized out>
(gdb) FAIL: gdb.base/vla-optimized-out.exp: o1: printed size of optimized out vla

This patch changes the gdb_test to check for the size of vla being
available or optimized out.  In either case, the test now passes.
---
 gdb/testsuite/gdb.base/vla-optimized-out.exp | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.base/vla-optimized-out.exp b/gdb/testsuite/gdb.base/vla-optimized-out.exp
index b16142ee329..9a83b7ff81b 100644
--- a/gdb/testsuite/gdb.base/vla-optimized-out.exp
+++ b/gdb/testsuite/gdb.base/vla-optimized-out.exp
@@ -40,8 +40,10 @@ proc vla_optimized_out {exe_suffix options} {
 	" = <optimized out>" \
 	"printed optimized out vla"
 
+    # On Intel the variable use of variable vla is optimized out but the size
+    # is available.  On Powerpc, the variable and the size are optimized out.
     gdb_test "p sizeof (a)" \
-	" = ($sizeof_result)" \
+	"( = ($sizeof_result)| = <optimized out>)" \
 	"printed size of optimized out vla"
 
     # At lower optimisation levels, the upper bound of the array is
-- 
2.31.1

Re: [PATCH] Powerpc, fix vla-optimized-out.exp test

[will schmidt]

On Thu, 2022-03-24 at 14:41 -0700, Carl Love wrote:
> GDB maintainers:
> 
> The vla-optimized-out.exp test has a check to print the size of
> variable a.  The test expects the size to be available even though the
> use of the variable has been optimized out.  This is true on Intel. 
> However, on Powerpc both the use and the size of the variable are
> optimized out.
> 
> This patch adds to the test to check for the size or optimized out. The
> change fixes the test failure on Powerpc.
> 
> The patch has been tested on a Power 10 system and on and Intel 64-bit
> system.  No regressions were seen.
> 
> Please let me know if this patch is acceptable for gdb mainline. 
> Thanks.
> 
>                     Carl Love
> 
> ------------------------------------------
> Powerpc, fix vla-optimized-out.exp test
> 
> The size of the variable vla is not optimized out on Intel inspite of the
> use of the variable use being optimized out.

The variable in this case is actually just 'a'.   The vla reference in
the exp appears to be a copy/paste leftover from the nearby vla-ptr.c
test.

> On Powerpc, the use of vla and the size of vla are both optimized out.

I fear this shortcuts the intent of the test.   Can you instead update
the test in a way that prevents 'a' from being optimized out? 

> 
> The output on Powerpc is:
> 
> p sizeof (a)
> $2 = <optimized out>
> (gdb) FAIL: gdb.base/vla-optimized-out.exp: o1: printed size of optimized out vla
> 
> This patch changes the gdb_test to check for the size of vla being
> available or optimized out.  In either case, the test now passes.
> ---
>  gdb/testsuite/gdb.base/vla-optimized-out.exp | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/gdb/testsuite/gdb.base/vla-optimized-out.exp b/gdb/testsuite/gdb.base/vla-optimized-out.exp
> index b16142ee329..9a83b7ff81b 100644
> --- a/gdb/testsuite/gdb.base/vla-optimized-out.exp
> +++ b/gdb/testsuite/gdb.base/vla-optimized-out.exp
> @@ -40,8 +40,10 @@ proc vla_optimized_out {exe_suffix options} {
>  	" = <optimized out>" \
>  	"printed optimized out vla"
> 
> +    # On Intel the variable use of variable vla is optimized out but the size
> +    # is available.  On Powerpc, the variable and the size are optimized out.
>      gdb_test "p sizeof (a)" \
> -	" = ($sizeof_result)" \
> +	"( = ($sizeof_result)| = <optimized out>)" \
>  	"printed size of optimized out vla"
> 
>      # At lower optimisation levels, the upper bound of the array is

Re: [PATCH] Powerpc, fix vla-optimized-out.exp test

[Carl Love]

Will:

> 
> The variable in this case is actually just 'a'.   The vla reference
> in
> the exp appears to be a copy/paste leftover from the nearby vla-ptr.c
> test.

Ok

> 
> > On Powerpc, the use of vla and the size of vla are both optimized
> > out.
> 
> I fear this shortcuts the intent of the test.   Can you instead
> update
> the test in a way that prevents 'a' from being optimized out? 

The test is run with -O1 and -03 optimization levels.  The test talks
about the the effect of lower and higher optimization leves,
specifically:

    # At higher optimisation levels, the array bounds themselves have           
    # been removed.  As such GDB can't be expected to know if the               
    # array contains _any_ elements at all.  It seems reasonable in             
    # that case to reply with 'no such vector element'.  

It seems to me that the test expects the value to be optimized out. 
Since the comments clearly talk about effects of the variable being
optimized out, changing the test to ensure variable a is not optimized
out would actually be consistent the point of the test.

                       Carl Love 

Re: [PATCH] Powerpc, fix vla-optimized-out.exp test

[Carl Love]

GDB maintainers, Will:

I updated the commit log and comments to say variable a not vla per
Will's comments.  The updated patch is below.

As mentioned earlier, I don't think it is appropriate to change the
test so variable a is not optimized out.  The test does expect that it
will be optimized out.

                        Carl 

-------------------------------------------------------------------

GDB maintainers:

The vla-optimized-out.exp test has a check to print the size of
variable a.  The test expects the size to be available even though the
use of the variable has been optimized out.  This is true on Intel. 
However, on Powerpc both the use and the size of the variable are
optimized out.

This patch adds to the test to check for the size or optimized out. The
change fixes the test failure on Powerpc.

The patch has been tested on a Power 10 system and on and Intel 64-bit
system.  No regressions were seen.

Please let me know if this patch is acceptable for gdb mainline. 
Thanks.

                    Carl Love
-------------------------------------------------
Powerpc, fix vla-optimized-out.exp test

The size of the variable a is not optimized out on Intel inspite of the
use of the variable use being optimized out.

On Powerpc, the use of variable a and the size of variable a are both
optimized out.

The output on Powerpc is:

p sizeof (a)
$2 = <optimized out>
(gdb) FAIL: gdb.base/vla-optimized-out.exp: o1: printed size of optimized out vla

This patch changes the gdb_test to check for the size of vla being
available or optimized out.  In either case, the test now passes.
---
 gdb/testsuite/gdb.base/vla-optimized-out.exp | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.base/vla-optimized-out.exp b/gdb/testsuite/gdb.base/vla-optimized-out.exp
index b16142ee329..0a25788cb34 100644
--- a/gdb/testsuite/gdb.base/vla-optimized-out.exp
+++ b/gdb/testsuite/gdb.base/vla-optimized-out.exp
@@ -40,8 +40,10 @@ proc vla_optimized_out {exe_suffix options} {
 	" = <optimized out>" \
 	"printed optimized out vla"
 
+    # On Intel the variable use of variable a is optimized out but the size is
+    # available.  On Powerpc, the variable and the size of a are optimized out.
     gdb_test "p sizeof (a)" \
-	" = ($sizeof_result)" \
+	"( = ($sizeof_result)| = <optimized out>)" \
 	"printed size of optimized out vla"
 
     # At lower optimisation levels, the upper bound of the array is
-- 
2.31.1

Re: [PATCH] Powerpc, fix vla-optimized-out.exp test

[Joel Brobecker]

Hello Carl,

Thanks for the patch.

> Powerpc, fix vla-optimized-out.exp test
> 
> The size of the variable a is not optimized out on Intel inspite of the
> use of the variable use being optimized out.
> 
> On Powerpc, the use of variable a and the size of variable a are both
> optimized out.

For me, it would be useful to include an annotated copy of the DWARF
info being produced on x86_64-linux where the size is available,
vs the DWARF being produced on PowerPC. This will help understand
what's happening and confirm that it is indeed valid for GDB to
print that the size has been optimized out.

> The output on Powerpc is:
> 
> p sizeof (a)
> $2 = <optimized out>
> (gdb) FAIL: gdb.base/vla-optimized-out.exp: o1: printed size of optimized out vla
> 
> This patch changes the gdb_test to check for the size of vla being
> available or optimized out.  In either case, the test now passes.
> ---
>  gdb/testsuite/gdb.base/vla-optimized-out.exp | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/gdb/testsuite/gdb.base/vla-optimized-out.exp b/gdb/testsuite/gdb.base/vla-optimized-out.exp
> index b16142ee329..0a25788cb34 100644
> --- a/gdb/testsuite/gdb.base/vla-optimized-out.exp
> +++ b/gdb/testsuite/gdb.base/vla-optimized-out.exp
> @@ -40,8 +40,10 @@ proc vla_optimized_out {exe_suffix options} {
>  	" = <optimized out>" \
>  	"printed optimized out vla"
>  
> +    # On Intel the variable use of variable a is optimized out but the size is
> +    # available.  On Powerpc, the variable and the size of a are optimized out.
>      gdb_test "p sizeof (a)" \
> -	" = ($sizeof_result)" \
> +	"( = ($sizeof_result)| = <optimized out>)" \
>  	"printed size of optimized out vla"

In situations like these, I would suggest using gdb_test_multiple
instead. I think it'll make the testcase more readable.

-- 
Joel

RE: [PATCH] Powerpc, fix vla-optimized-out.exp test

[Carl Love]

Joel:

I have been talking with the gcc developers to understand more about
how DWARF reports the type and size of the variable in the DWARF output
to answer your question below.

On Sun, 2022-04-17 at 08:19 -0700, Joel Brobecker wrote:
> Hello Carl,
> 
> Thanks for the patch.
> 
> > Powerpc, fix vla-optimized-out.exp test
> > 
> > The size of the variable a is not optimized out on Intel inspite of
> > the
> > use of the variable use being optimized out.
> > 
> > On Powerpc, the use of variable a and the size of variable a are
> > both
> > optimized out.
> 
> For me, it would be useful to include an annotated copy of the DWARF
> info being produced on x86_64-linux where the size is available,
> vs the DWARF being produced on PowerPC. This will help understand
> what's happening and confirm that it is indeed valid for GDB to
> print that the size has been optimized out

I am still learning the DWARF format but here is what I have from my
discussions.  The dwarf is for the vla-optimized-out.c program compiled
with -O1 which corresponds to the case where the <optimized out>
message gets printed.  

Contents of the .debug_info section:

  Compilation Unit @ offset 0x0:
   Length:        0xef (32-bit)
   Version:       5
   Unit Type:     DW_UT_compile (1)
   Abbrev Offset: 0x0
   Pointer Size:  8
 <0><c>: Abbrev Number: 2 (DW_TAG_compile_unit)
    <d>   DW_AT_producer    : (indirect string, offset: 0x3e): GNU C17 11.2.1 20220127 (Red Hat 11.2.1-9) -msecure-plt -mtune=power9 -mcpu=power9 -g -O1 -fno-stack-protector
    <11>   DW_AT_language    : 29	(C11)
    <12>   DW_AT_name        : (indirect string, offset: 0xb2): /.../gdb/testsuite/gdb.base/vla-optimized-out.c
    <16>   DW_AT_comp_dir    : (indirect string, offset: 0x0): /.../gdb/testsuite
    <1a>   DW_AT_low_pc      : 0x1000068c
    <22>   DW_AT_high_pc     : 0x5c
    <2a>   DW_AT_stmt_list   : 0x0
 <1><2e>: Abbrev Number: 3 (DW_TAG_subprogram)
    <2f>   DW_AT_external    : 1
    <2f>   DW_AT_name        : (indirect string, offset: 0xad): main
    <33>   DW_AT_decl_file   : 1
    <34>   DW_AT_decl_line   : 37
    <35>   DW_AT_decl_column : 1
    <36>   DW_AT_prototyped  : 1
    <36>   DW_AT_type        : <0x7d>
    <3a>   DW_AT_low_pc      : 0x100006a0
    <42>   DW_AT_high_pc     : 0x48
    <4a>   DW_AT_frame_base  : 1 byte block: 9c 	(DW_OP_call_frame_cfa)
    <4c>   DW_AT_call_all_calls: 1
    <4c>   DW_AT_sibling     : <0x7d>
 <2><50>: Abbrev Number: 4 (DW_TAG_variable)
    <51>   DW_AT_name        : j
    <53>   DW_AT_decl_file   : 1
    <54>   DW_AT_decl_line   : 39
    <55>   DW_AT_decl_column : 16
    <56>   DW_AT_type        : <0x84>
    <5a>   DW_AT_location    : 2 byte block: 91 70 	(DW_OP_fbreg: -16)
 <2><5d>: Abbrev Number: 5 (DW_TAG_variable)
    <5e>   DW_AT_name        : i
    <60>   DW_AT_decl_file   : 1
    <61>   DW_AT_decl_line   : 40
    <62>   DW_AT_decl_column : 7
    <63>   DW_AT_type        : <0x7d>
    <67>   DW_AT_location    : 0x10 (location list)
    <6b>   DW_AT_GNU_locviews: 0xc
 <2><6f>: Abbrev Number: 6 (DW_TAG_call_site)
    <70>   DW_AT_call_return_pc: 0x100006c4
    <78>   DW_AT_call_origin : <0x89>
 <2><7c>: Abbrev Number: 0
 <1><7d>: Abbrev Number: 7 (DW_TAG_base_type)
    <7e>   DW_AT_byte_size   : 4
    <7f>   DW_AT_encoding    : 5	(signed)
    <80>   DW_AT_name        : int
 <1><84>: Abbrev Number: 8 (DW_TAG_volatile_type)
    <85>   DW_AT_type        : <0x7d>
 <1><89>: Abbrev Number: 9 (DW_TAG_subprogram)
    <8a>   DW_AT_external    : 1
    <8a>   DW_AT_name        : f1
    <8d>   DW_AT_decl_file   : 1
    <8e>   DW_AT_decl_line   : 29
    <8f>   DW_AT_decl_column : 1
    <90>   DW_AT_prototyped  : 1
    <90>   DW_AT_type        : <0x7d>
    <94>   DW_AT_low_pc      : 0x1000068c
    <9c>   DW_AT_high_pc     : 0x14
    <a4>   DW_AT_frame_base  : 1 byte block: 9c 	(DW_OP_call_frame_cfa)
    <a6>   DW_AT_call_all_calls: 1
    <a6>   DW_AT_sibling     : <0xc7>
 <2><aa>: Abbrev Number: 10 (DW_TAG_formal_parameter)
    <ab>   DW_AT_name        : i
    <ad>   DW_AT_decl_file   : 1
    <ae>   DW_AT_decl_line   : 29
    <af>   DW_AT_decl_column : 9
    <b0>   DW_AT_type        : <0x7d>
    <b4>   DW_AT_location    : 0x20 (location list)
    <b8>   DW_AT_GNU_locviews: 0x1c
 <2><bc>: Abbrev Number: 11 (DW_TAG_variable)
    <bd>   DW_AT_name        : a           <- Variable a, array of (unsigned char)
    <bf>   DW_AT_decl_file   : 1
    <c0>   DW_AT_decl_line   : 31
    <c1>   DW_AT_decl_column : 8
    <c2>   DW_AT_type        : <0xc7>      <- a is type entry c7
    
 <2><c6>: Abbrev Number: 0
 <1><c7>: Abbrev Number: 12 (DW_TAG_array_type)   <- array type entry
    <c8>   DW_AT_type        : <0xeb>             <- array element type eb
    <cc>   DW_AT_sibling     : <0xe4>
 <2><d0>: Abbrev Number: 13 (DW_TAG_subrange_type)
    <d1>   DW_AT_type        : <0xe4>

        From what I was told, the following DW_AT_upper_bound gives
        the upper bound for calculating the size of the array.  I believe
        the size is given by (upper-bound (13) + 1 - lower bound(default 0))
	          * size of base type (8) = 112
	The program declares char a[6] so I would expect the size to be 6 bytes not
	112.  Either way, it does look like the info is there, not that I claim
	to completely understand the DWARF output.  Am I missing something
	which results in gdb saying the size is optimized out?
					       
    <d5>   DW_AT_upper_bound : 13 byte block: a3 1 53 23 1 8 20 24 8 20 26 31 1c 	(DW_OP_entry_value: (DW_OP_reg3 (r3)); DW_OP_plus_uconst: 1; DW_OP_const1u: 32; DW_OP_shl; DW_OP_const1u: 32; DW_OP_shra; DW_OP_lit1; DW_OP_minus)
 <2><e3>: Abbrev Number: 0
 <1><e4>: Abbrev Number: 1 (DW_TAG_base_type)
    <e5>   DW_AT_byte_size   : 8
    <e6>   DW_AT_encoding    : 7	(unsigned)
    <e7>   DW_AT_name        : (indirect string, offset: 0x2c): long unsigned int
 <1><eb>: Abbrev Number: 1 (DW_TAG_base_type)        Here is the base type
    <ec>   DW_AT_byte_size   : 1
    <ed>   DW_AT_encoding    : 8	(unsigned char)
    <ee>   DW_AT_name        : (indirect string, offset: 0x127): char
 <1><f2>: Abbrev Number: 0

                    Carl

Re: [PATCH] Powerpc, fix vla-optimized-out.exp test

[Joel Brobecker]

Hi everyone,

On Thu, Jun 09, 2022 at 10:23:58AM -0700, Carl Love wrote:
> Joel:
> 
> I have been talking with the gcc developers to understand more about
> how DWARF reports the type and size of the variable in the DWARF output
> to answer your question below.

Thanks Carl.

Could someone else take a look and help Carl? I've been meaning to
get to this, but haven't been able to get to this, not even on weekends,
and I don't see myself having time for quite a while, unfortunately :-(.

> 
> On Sun, 2022-04-17 at 08:19 -0700, Joel Brobecker wrote:
> > Hello Carl,
> > 
> > Thanks for the patch.
> > 
> > > Powerpc, fix vla-optimized-out.exp test
> > > 
> > > The size of the variable a is not optimized out on Intel inspite of
> > > the
> > > use of the variable use being optimized out.
> > > 
> > > On Powerpc, the use of variable a and the size of variable a are
> > > both
> > > optimized out.
> > 
> > For me, it would be useful to include an annotated copy of the DWARF
> > info being produced on x86_64-linux where the size is available,
> > vs the DWARF being produced on PowerPC. This will help understand
> > what's happening and confirm that it is indeed valid for GDB to
> > print that the size has been optimized out
> 
> I am still learning the DWARF format but here is what I have from my
> discussions.  The dwarf is for the vla-optimized-out.c program compiled
> with -O1 which corresponds to the case where the <optimized out>
> message gets printed.  
> 
> Contents of the .debug_info section:
> 
>   Compilation Unit @ offset 0x0:
>    Length:        0xef (32-bit)
>    Version:       5
>    Unit Type:     DW_UT_compile (1)
>    Abbrev Offset: 0x0
>    Pointer Size:  8
>  <0><c>: Abbrev Number: 2 (DW_TAG_compile_unit)
>     <d>   DW_AT_producer    : (indirect string, offset: 0x3e): GNU C17 11.2.1 20220127 (Red Hat 11.2.1-9) -msecure-plt -mtune=power9 -mcpu=power9 -g -O1 -fno-stack-protector
>     <11>   DW_AT_language    : 29	(C11)
>     <12>   DW_AT_name        : (indirect string, offset: 0xb2): /.../gdb/testsuite/gdb.base/vla-optimized-out.c
>     <16>   DW_AT_comp_dir    : (indirect string, offset: 0x0): /.../gdb/testsuite
>     <1a>   DW_AT_low_pc      : 0x1000068c
>     <22>   DW_AT_high_pc     : 0x5c
>     <2a>   DW_AT_stmt_list   : 0x0
>  <1><2e>: Abbrev Number: 3 (DW_TAG_subprogram)
>     <2f>   DW_AT_external    : 1
>     <2f>   DW_AT_name        : (indirect string, offset: 0xad): main
>     <33>   DW_AT_decl_file   : 1
>     <34>   DW_AT_decl_line   : 37
>     <35>   DW_AT_decl_column : 1
>     <36>   DW_AT_prototyped  : 1
>     <36>   DW_AT_type        : <0x7d>
>     <3a>   DW_AT_low_pc      : 0x100006a0
>     <42>   DW_AT_high_pc     : 0x48
>     <4a>   DW_AT_frame_base  : 1 byte block: 9c 	(DW_OP_call_frame_cfa)
>     <4c>   DW_AT_call_all_calls: 1
>     <4c>   DW_AT_sibling     : <0x7d>
>  <2><50>: Abbrev Number: 4 (DW_TAG_variable)
>     <51>   DW_AT_name        : j
>     <53>   DW_AT_decl_file   : 1
>     <54>   DW_AT_decl_line   : 39
>     <55>   DW_AT_decl_column : 16
>     <56>   DW_AT_type        : <0x84>
>     <5a>   DW_AT_location    : 2 byte block: 91 70 	(DW_OP_fbreg: -16)
>  <2><5d>: Abbrev Number: 5 (DW_TAG_variable)
>     <5e>   DW_AT_name        : i
>     <60>   DW_AT_decl_file   : 1
>     <61>   DW_AT_decl_line   : 40
>     <62>   DW_AT_decl_column : 7
>     <63>   DW_AT_type        : <0x7d>
>     <67>   DW_AT_location    : 0x10 (location list)
>     <6b>   DW_AT_GNU_locviews: 0xc
>  <2><6f>: Abbrev Number: 6 (DW_TAG_call_site)
>     <70>   DW_AT_call_return_pc: 0x100006c4
>     <78>   DW_AT_call_origin : <0x89>
>  <2><7c>: Abbrev Number: 0
>  <1><7d>: Abbrev Number: 7 (DW_TAG_base_type)
>     <7e>   DW_AT_byte_size   : 4
>     <7f>   DW_AT_encoding    : 5	(signed)
>     <80>   DW_AT_name        : int
>  <1><84>: Abbrev Number: 8 (DW_TAG_volatile_type)
>     <85>   DW_AT_type        : <0x7d>
>  <1><89>: Abbrev Number: 9 (DW_TAG_subprogram)
>     <8a>   DW_AT_external    : 1
>     <8a>   DW_AT_name        : f1
>     <8d>   DW_AT_decl_file   : 1
>     <8e>   DW_AT_decl_line   : 29
>     <8f>   DW_AT_decl_column : 1
>     <90>   DW_AT_prototyped  : 1
>     <90>   DW_AT_type        : <0x7d>
>     <94>   DW_AT_low_pc      : 0x1000068c
>     <9c>   DW_AT_high_pc     : 0x14
>     <a4>   DW_AT_frame_base  : 1 byte block: 9c 	(DW_OP_call_frame_cfa)
>     <a6>   DW_AT_call_all_calls: 1
>     <a6>   DW_AT_sibling     : <0xc7>
>  <2><aa>: Abbrev Number: 10 (DW_TAG_formal_parameter)
>     <ab>   DW_AT_name        : i
>     <ad>   DW_AT_decl_file   : 1
>     <ae>   DW_AT_decl_line   : 29
>     <af>   DW_AT_decl_column : 9
>     <b0>   DW_AT_type        : <0x7d>
>     <b4>   DW_AT_location    : 0x20 (location list)
>     <b8>   DW_AT_GNU_locviews: 0x1c
>  <2><bc>: Abbrev Number: 11 (DW_TAG_variable)
>     <bd>   DW_AT_name        : a           <- Variable a, array of (unsigned char)
>     <bf>   DW_AT_decl_file   : 1
>     <c0>   DW_AT_decl_line   : 31
>     <c1>   DW_AT_decl_column : 8
>     <c2>   DW_AT_type        : <0xc7>      <- a is type entry c7
>     
>  <2><c6>: Abbrev Number: 0
>  <1><c7>: Abbrev Number: 12 (DW_TAG_array_type)   <- array type entry
>     <c8>   DW_AT_type        : <0xeb>             <- array element type eb
>     <cc>   DW_AT_sibling     : <0xe4>
>  <2><d0>: Abbrev Number: 13 (DW_TAG_subrange_type)
>     <d1>   DW_AT_type        : <0xe4>
> 
>         From what I was told, the following DW_AT_upper_bound gives
>         the upper bound for calculating the size of the array.  I believe
>         the size is given by (upper-bound (13) + 1 - lower bound(default 0))
> 	          * size of base type (8) = 112
> 	The program declares char a[6] so I would expect the size to be 6 bytes not
> 	112.  Either way, it does look like the info is there, not that I claim
> 	to completely understand the DWARF output.  Am I missing something
> 	which results in gdb saying the size is optimized out?
> 					       
>     <d5>   DW_AT_upper_bound : 13 byte block: a3 1 53 23 1 8 20 24 8 20 26 31 1c 	(DW_OP_entry_value: (DW_OP_reg3 (r3)); DW_OP_plus_uconst: 1; DW_OP_const1u: 32; DW_OP_shl; DW_OP_const1u: 32; DW_OP_shra; DW_OP_lit1; DW_OP_minus)
>  <2><e3>: Abbrev Number: 0
>  <1><e4>: Abbrev Number: 1 (DW_TAG_base_type)
>     <e5>   DW_AT_byte_size   : 8
>     <e6>   DW_AT_encoding    : 7	(unsigned)
>     <e7>   DW_AT_name        : (indirect string, offset: 0x2c): long unsigned int
>  <1><eb>: Abbrev Number: 1 (DW_TAG_base_type)        Here is the base type
>     <ec>   DW_AT_byte_size   : 1
>     <ed>   DW_AT_encoding    : 8	(unsigned char)
>     <ee>   DW_AT_name        : (indirect string, offset: 0x127): char
>  <1><f2>: Abbrev Number: 0
> 
>                     Carl
> 
> 

-- 
Joel