From: Joel Brobecker <brobecker@adacore.com>
To: Carl Love <cel@us.ibm.com>
Cc: Joel Brobecker <brobecker@adacore.com>,
gdb-patches@sourceware.org,
will schmidt <will_schmidt@vnet.ibm.com>
Subject: Re: [PATCH] Powerpc, fix vla-optimized-out.exp test
Date: Thu, 23 Jun 2022 07:19:37 -0700 [thread overview]
Message-ID: <YrR2eUYLXgsEHW/u@adacore.com> (raw)
In-Reply-To: <17e5bd9e5680588b0442206e67e09684a342a37a.camel@us.ibm.com>
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
prev parent reply other threads:[~2022-06-23 14:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-24 21:41 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 message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YrR2eUYLXgsEHW/u@adacore.com \
--to=brobecker@adacore.com \
--cc=cel@us.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=will_schmidt@vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).