Re: [C++0x] implementing forward declarations for enums

[Rodrigo Rivas <rodrigorivascosta at gmail dot com>]

On Tue, Oct 12, 2010 at 9:15 PM, Jason Merrill <jason@redhat.com> wrote:
> I think that's fine. ÂIn real code, presumably some other file will provide
> the enumerator list for V, and otherwise treating it as incomplete is a good
> enough approximation; an opaque enum declaration is not a definition even
> though the type is considered complete in the C++ sense.
The only problem I see here is that the debugger will not show the
value of any variable of this type. Granted, the constants are not
known, so the debugger cannot show them. Curiously, it can show the
value if casted to integer:

(With STABS)
(gdb) p z
$1 = <incomplete type>
(gdb) p (int)z
$2 = 0

> If one file has the enumerator list and another doesn't, does GDB handle
> that properly with DWARF output (making the list available while debugging
> code from the file that doesn't have the list)?
No, it looks like each compilation unit has its own copy of all the
types declared into it, and then the variables are bound to the debug
info of their local compilation unit.

So:

//a.cpp:
enum V : int;
V z;

//b.cpp:
enum V : int;
extern V z;
V z2;
enum V : int { v1, v2, v3 };

Then, running:
$ g++ -O0 -gdwarf-2 -std=c++0x a.cpp b.cpp
And (I've just learnt this!):
$ objdump -W a.out
[...]
  Compilation Unit @ offset 0x0:
[...]
 <1><96>: Abbrev Number: 7 (DW_TAG_enumeration_type)
    <97>   DW_AT_name        : V	
    <99>   DW_AT_byte_size   : 4	
    <9a>   DW_AT_decl_file   : 1	
    <9b>   DW_AT_decl_line   : 8	
 <1><9c>: Abbrev Number: 6 (DW_TAG_variable)
    <9d>   DW_AT_name        : z	
    <9f>   DW_AT_decl_file   : 1	
    <a0>   DW_AT_decl_line   : 9	
    <a1>   DW_AT_type        : <0x96>	
    <a5>   DW_AT_external    : 1	
    <a6>   DW_AT_location    : 5 byte block: 3 48 96 4 8 	(DW_OP_addr: 8049648)
[...]
  Compilation Unit @ offset 0xad:
[...]
 <1><d6>: Abbrev Number: 2 (DW_TAG_enumeration_type)
    <d7>   DW_AT_name        : V	
    <d9>   DW_AT_byte_size   : 4	
    <da>   DW_AT_decl_file   : 1	
    <db>   DW_AT_decl_line   : 5	
    <dc>   DW_AT_sibling     : <0xf0>	
 <2><e0>: Abbrev Number: 3 (DW_TAG_enumerator)
    <e1>   DW_AT_name        : v1	
    <e4>   DW_AT_const_value : 0	
 <2><e5>: Abbrev Number: 3 (DW_TAG_enumerator)
    <e6>   DW_AT_name        : v2	
    <e9>   DW_AT_const_value : 1	
 <2><ea>: Abbrev Number: 3 (DW_TAG_enumerator)
    <eb>   DW_AT_name        : v3	
    <ee>   DW_AT_const_value : 2	
 <1><113>: Abbrev Number: 6 (DW_TAG_variable)
    <114>   DW_AT_name        : z2	
    <117>   DW_AT_decl_file   : 1	
    <118>   DW_AT_decl_line   : 3	
    <119>   DW_AT_type        : <0xd6>	
    <11d>   DW_AT_external    : 1	
    <11e>   DW_AT_location    : 5 byte block: 3 4c 96 4 8 	(DW_OP_addr: 804964c)

I'd say that this just cannot be solved! I tried with
-feliminate-dwarf2-dups, but no difference.

>> Other option would be to use the Âflag of the VALUE_LIST to modify the
>> debuggers backed.
>
> Right; earlier I was suggesting to change ENUM_HAS_VALUE_LIST_P to be a
> language-independent macro, something like "ENUM_LACKS_VALUE_LIST".

I've just done this, but the flag is currently not used anywhere. But
it will be there if needed...

I you agree that it is ready for commit, I'll update it and re-write
the changelog (I always feel lazy about the changelog!).

Regards.
Rodrigo