DWARF question about size of a variable

DWARF question about size of a variable

[Carl Love]

GCC developers:

Is there dwarf information that gives the size of a variable?  I have a
test case which when run on Intel gdb can print the size of an
optimized out variable.  However on PowerPC, gdb says the size
information for the variable is optimized out.  Is there some DWARF
information that I can print on the Intel binary that shows the size
information for the variable even though the variable is optimized out?
Then by comparison on PowerPC I would expect the DWARF information
would either say the size of the variable is optimized out or there is
no information available.

Here is the test program for the test.

#include "../lib/attributes.h"

int
#ifdef NOCLONE
__attribute__((noinline,weak)) ATTRIBUTE_NOCLONE
#else
__attribute__((noinline,weak))
#endif
f1 (int i)
{
  char a[i + 1];
  a[0] = 5;
  return a[0];
}

int
main (void)
{
  volatile int j;
  int i = 5;
  asm volatile ("" : "=r" (i) : "0" (i));
  j = f1 (i);
  return 0;
}

So when the above test program is compiled with -03 and run on Intel we
have the following:

(gdb) break f1
Breakpoint 1 at 0x1150: file /.../gdb/testsuite/gdb.base/vla-optimized-out.c, line 30.
(gdb) r
Starting program: /.../gdb/testsuite/outputs/gdb.base/vla-optimized-out/vla-optimized-out-o3 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, f1 (i=5)
    at /.../gdb/testsuite/gdb.base/vla-optimized-out.c:30
30	{
(gdb) p a
$1 = <optimized out>
(gdb) p sizeof( a)
$2 = 6                              <- the variable is optimized out but apparently 
                                       the size info is still accessible


When I compile and run the same program on PowerPC:

(gdb) break f1
Breakpoint 1 at 0x100006e0: file /.../gdb/testsuite/gdb.base/vla-optimized-out.c, line 33.
(gdb) r
Starting program: /home/carll/GDB/build-current/.../vla-optimized-out-3 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, f1 (i=5)
    at /.../gdb/testsuite/gdb.base/vla-optimized-out.c:33
33	  return a[0];
(gdb) p a
$1 = <optimized out>
(gdb) p sizeof (a)
$2 = <optimized out>                  <- the variable is optimized out and the size
                                         is not available.

Anyway, I am looking for some DWARF info on Intel and PowerPC which
will show why Intel can display the size of the variable but PowerPC
can not.  Thanks for you help.

                    Carl Love

Re: DWARF question about size of a variable

[Eric Botcazou]

> Is there dwarf information that gives the size of a variable?  I have a
> test case which when run on Intel gdb can print the size of an
> optimized out variable.  However on PowerPC, gdb says the size
> information for the variable is optimized out.  Is there some DWARF
> information that I can print on the Intel binary that shows the size
> information for the variable even though the variable is optimized out?
> Then by comparison on PowerPC I would expect the DWARF information
> would either say the size of the variable is optimized out or there is
> no information available.

If you try to debug at an optimization level higher than -Og, your mileage may 
vary and depend on various factors; that's apparently an example where the 
debug info is slightly less damaged at -O3 on x86 than on PowerPC, but there 
are probably cases where this will be the other way around.

-- 
Eric Botcazou

Re: DWARF question about size of a variable

[Michael Matz]

Hello,

On Wed, 8 Jun 2022, Carl Love via Gcc wrote:

> Is there dwarf information that gives the size of a variable?

Yes, it's in the type description.  For array types the siblings of it 
give the index types and ranges.  If that range is 
computed at runtime DWARF will (try to) express it as an expression in 
terms of other available values (like registers, constants, or memory), 
and as such can also change depending on where (at which PC) you evaluate 
that expression (and the expression itself can also change per PC).  For 
instance, in your example, on x86 with -O3 we have these relevant DWARF 
snippets (readelf -wi):

 <2><a1e>: Abbrev Number: 12 (DW_TAG_variable)
    <a1f>   DW_AT_name        : a
    <a24>   DW_AT_type        : <0xa29>

So, 'a' is a variable of type 0xa29, which is:

 <1><a29>: Abbrev Number: 13 (DW_TAG_array_type)
    <a2a>   DW_AT_type        : <0xa4a>
    <a2e>   DW_AT_sibling     : <0xa43>
 <2><a32>: Abbrev Number: 14 (DW_TAG_subrange_type)
    <a33>   DW_AT_type        : <0xa43>
    <a37>   DW_AT_upper_bound : 10 byte block: 75 1 8 20 24 8 20 26 31 1c       
(DW_OP_breg5 (rdi): 1; DW_OP_const1u: 32; DW_OP_shl; DW_OP_const1u: 32; 
DW_OP_shra; DW_OP_lit1; DW_OP_minus)
 <2><a42>: Abbrev Number: 0

So, type 0xa29 is an array type, whose element type is 0xa4a (which will 
turn out to be a signed char), and whose (single) dimension type is 0xa43 
(unsigned long) with an upper bound that is runtime computed, see below.
The referenced types from that are:

 <1><a43>: Abbrev Number: 1 (DW_TAG_base_type)
    <a44>   DW_AT_byte_size   : 8
    <a45>   DW_AT_encoding    : 7       (unsigned)
    <a46>   DW_AT_name        : (indirect string, offset: 0x13b): long unsigned int

 <1><a4a>: Abbrev Number: 1 (DW_TAG_base_type)
    <a4b>   DW_AT_byte_size   : 1
    <a4c>   DW_AT_encoding    : 6       (signed char)
    <a4d>   DW_AT_name        : (indirect string, offset: 0x1ce): char

With that gdb has all information to compute the size of this array 
variable in its scope ((upper-bound + 1 minus lower-bound (default 0)) 
times sizeof(basetype)).  Compare the above for instance with the 
debuginfo generated at -O0, only the upper-range expression changes:

 <2><a1f>: Abbrev Number: 10 (DW_TAG_subrange_type)
    <a20>   DW_AT_type        : <0xa29>
    <a24>   DW_AT_upper_bound : 3 byte block: 91 68 6   (DW_OP_fbreg: -24; 
DW_OP_deref)

Keep in mind that DWARF expressions are based on a simple stack machine.
So, for instance, the computation for the upper bound in the O3 case is:
 ((register %rdi + 1) << 32 >> 32) - 1
(i.e. basically the 32-to-64 signextension of %rdi).

On ppc I assume that either the upper_bound attribute isn't there or 
contains an uninformative expression (or one that isn't valid at the 
program-counter gdb stops at), in which case you would want to look at 
dwarf2out.cc:subrange_type_die or add_subscript_info (look for 
TYPE_MAX_VALUE of the subscripts domain type).  Hope this helps.


Ciao,
Michael.