* [PATCH] Powerpc, fix vla-optimized-out.exp test
@ 2022-03-24 21:41 Carl Love
2022-03-24 22:46 ` will schmidt
0 siblings, 1 reply; 7+ messages in thread
From: Carl Love @ 2022-03-24 21:41 UTC (permalink / raw)
To: gdb-patches, cel; +Cc: Rogerio Alves, Will Schmidt
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH] Powerpc, fix vla-optimized-out.exp test
2022-03-24 21:41 [PATCH] Powerpc, fix vla-optimized-out.exp test Carl Love
@ 2022-03-24 22:46 ` will schmidt
2022-03-25 15:26 ` Carl Love
0 siblings, 1 reply; 7+ messages in thread
From: will schmidt @ 2022-03-24 22:46 UTC (permalink / raw)
To: Carl Love, gdb-patches; +Cc: Rogerio Alves
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH] Powerpc, fix vla-optimized-out.exp test
2022-03-24 22:46 ` will schmidt
@ 2022-03-25 15:26 ` Carl Love
2022-03-28 15:34 ` Carl Love
0 siblings, 1 reply; 7+ messages in thread
From: Carl Love @ 2022-03-25 15:26 UTC (permalink / raw)
To: will schmidt, gdb-patches; +Cc: Rogerio Alves, cel
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH] Powerpc, fix vla-optimized-out.exp test
2022-03-25 15:26 ` Carl Love
@ 2022-03-28 15:34 ` Carl Love
2022-04-17 15:19 ` Joel Brobecker
0 siblings, 1 reply; 7+ messages in thread
From: Carl Love @ 2022-03-28 15:34 UTC (permalink / raw)
To: will schmidt, gdb-patches, cel; +Cc: Rogerio Alves
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH] Powerpc, fix vla-optimized-out.exp test
2022-03-28 15:34 ` Carl Love
@ 2022-04-17 15:19 ` Joel Brobecker
2022-06-09 17:23 ` Carl Love
0 siblings, 1 reply; 7+ messages in thread
From: Joel Brobecker @ 2022-04-17 15:19 UTC (permalink / raw)
To: Carl Love via Gdb-patches
Cc: will schmidt, cel, Rogerio Alves, 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
^ permalink raw reply [flat|nested] 7+ messages in thread* RE: [PATCH] Powerpc, fix vla-optimized-out.exp test
2022-04-17 15:19 ` Joel Brobecker
@ 2022-06-09 17:23 ` Carl Love
2022-06-23 14:19 ` Joel Brobecker
0 siblings, 1 reply; 7+ messages in thread
From: Carl Love @ 2022-06-09 17:23 UTC (permalink / raw)
To: Joel Brobecker, cel, gdb-patches
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH] Powerpc, fix vla-optimized-out.exp test
2022-06-09 17:23 ` Carl Love
@ 2022-06-23 14:19 ` Joel Brobecker
0 siblings, 0 replies; 7+ messages in thread
From: Joel Brobecker @ 2022-06-23 14:19 UTC (permalink / raw)
To: Carl Love; +Cc: Joel Brobecker, gdb-patches, will schmidt
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-06-23 14:19 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-24 21:41 [PATCH] Powerpc, fix vla-optimized-out.exp test Carl Love
2022-03-24 22:46 ` will schmidt
2022-03-25 15:26 ` Carl Love
2022-03-28 15:34 ` Carl Love
2022-04-17 15:19 ` Joel Brobecker
2022-06-09 17:23 ` Carl Love
2022-06-23 14:19 ` Joel Brobecker
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).