Static class members & DWARF

Static class members & DWARF

[Keith Seitz]

Hi,

Consider the following simple class:

class jvstatic
{
   public static int STATIC = 1;
}

Looking at the DWARF info for this class, I see:

  <1><107>: Abbrev Number: 2 (DW_TAG_class_type)
     <108>   DW_AT_name        : (indirect string, offset: 0xdf): 
jvstatic
     <10c>   DW_AT_byte_size   : 4
     <10d>   DW_AT_decl_file   : 1
     <10e>   DW_AT_decl_line   : 0
     <10f>   DW_AT_containing_type: <0x17b>
     <113>   DW_AT_sibling     : <0x17b>
  <2><117>: Abbrev Number: 3 (DW_TAG_inheritance)
     <118>   DW_AT_type        : <0x17b>
     <11c>   DW_AT_data_member_location: 2 byte block: 23 0 
(DW_OP_plus_uconst: 0)
     <11f>   DW_AT_accessibility: 1      (public)
  <2><120>: Abbrev Number: 4 (DW_TAG_member)
     <121>   DW_AT_name        : (indirect string, offset: 0x123): 
STATIC
     <125>   DW_AT_decl_file   : 1
     <126>   DW_AT_decl_line   : 0
     <127>   DW_AT_MIPS_linkage_name: (indirect string, offset: 0xca): 
_ZN8jvstatic6STATICE
     <12b>   DW_AT_type        : <0x181>
     <12f>   DW_AT_external    : 1
     <130>   DW_AT_declaration : 1

Pursuant to the DWARF3 specification (sec 4.1 #6), I would expect to 
subsequently see a DIE with DW_TAG_variable which refers to DIE <120> 
(via DW_AT_specification). Alas, this DIE does not appear in the debug 
info at all.

Does java operate differently from C++ (which follows the DWARF 
specification)?

Keith

PS. This causes gdb to report jvstatic.STATIC as "optimized out" when, 
in fact, it is not. [This is because I am removing 
DW_AT_MIPS_linkage_name from gdb, and this works on CVS HEAD *only* 
because gdb finds the linkage name in the minimal symbol table. A 
convenient workaround for many of gdb's sins.]

Re: Static class members & DWARF

[Andrew Haley]

On 03/03/2010 07:48 PM, Keith Seitz wrote:
> Hi,
> 
> Consider the following simple class:
> 
> class jvstatic
> {
>   public static int STATIC = 1;
> }
> 
> Looking at the DWARF info for this class, I see:
> 
>  <1><107>: Abbrev Number: 2 (DW_TAG_class_type)
>     <108>   DW_AT_name        : (indirect string, offset: 0xdf): jvstatic
>     <10c>   DW_AT_byte_size   : 4
>     <10d>   DW_AT_decl_file   : 1
>     <10e>   DW_AT_decl_line   : 0
>     <10f>   DW_AT_containing_type: <0x17b>
>     <113>   DW_AT_sibling     : <0x17b>
>  <2><117>: Abbrev Number: 3 (DW_TAG_inheritance)
>     <118>   DW_AT_type        : <0x17b>
>     <11c>   DW_AT_data_member_location: 2 byte block: 23 0
> (DW_OP_plus_uconst: 0)
>     <11f>   DW_AT_accessibility: 1      (public)
>  <2><120>: Abbrev Number: 4 (DW_TAG_member)
>     <121>   DW_AT_name        : (indirect string, offset: 0x123): STATIC
>     <125>   DW_AT_decl_file   : 1
>     <126>   DW_AT_decl_line   : 0
>     <127>   DW_AT_MIPS_linkage_name: (indirect string, offset: 0xca):
> _ZN8jvstatic6STATICE
>     <12b>   DW_AT_type        : <0x181>
>     <12f>   DW_AT_external    : 1
>     <130>   DW_AT_declaration : 1
> 
> Pursuant to the DWARF3 specification (sec 4.1 #6), I would expect to
> subsequently see a DIE with DW_TAG_variable which refers to DIE <120>
> (via DW_AT_specification). Alas, this DIE does not appear in the debug
> info at all.
> 
> Does java operate differently from C++ (which follows the DWARF
> specification)?

Only by mistake.  gcj itself has no code to generate DWARF: we create the
data structures and hope that the back end will do The Right Thing with
them.

I suppose that the C++ compiler generates something different from gcj.
I don't know why.

Andrew.