Comment # 9 on bug 936563 from Ulrich Weigand

It seems GCC generates inconsistent debug info here:

        .4byte  .LASF173         # DW_AT_name: "felem_reduce"
        .byte   0x1      # DW_AT_decl_file (ecp_nistp224.c)
        .2byte  0x235    # DW_AT_decl_line
                         # DW_AT_prototyped
        .byte   0x1      # DW_AT_inline
        .4byte  0x11ee   # DW_AT_sibling
        .uleb128 0x1f    # (DIE (0x11a6) DW_TAG_formal_parameter)
        .ascii "out\0"   # DW_AT_name
        .byte   0x1      # DW_AT_decl_file (ecp_nistp224.c)
        .2byte  0x235    # DW_AT_decl_line
        .4byte  0xd63    # DW_AT_type
        .uleb128 0x1f    # (DIE (0x11b2) DW_TAG_formal_parameter)
        .ascii "in\0"    # DW_AT_name
        .byte   0x1      # DW_AT_decl_file (ecp_nistp224.c)
        .2byte  0x235    # DW_AT_decl_line
        .4byte  0x11ee   # DW_AT_type
        .uleb128 0x2e    # (DIE (0x11bd) DW_TAG_variable)
        .4byte  .LASF174         # DW_AT_name: "two127p15"
        .byte   0x1      # DW_AT_decl_file (ecp_nistp224.c)
        .2byte  0x237    # DW_AT_decl_line
        .4byte  0x109e   # DW_AT_type
        .uleb128 0x2e    # (DIE (0x11c9) DW_TAG_variable)
        .4byte  .LASF175         # DW_AT_name: "two127m71"
        .byte   0x1      # DW_AT_decl_file (ecp_nistp224.c)
        .2byte  0x239    # DW_AT_decl_line
        .4byte  0x109e   # DW_AT_type

For the local variables in felem_reduce: two127p15, two127m71 etc. GCC emits
DIEs using the abbrev code 0x2e.  That abbrev is defined as:

        .uleb128 0x2e    # (abbrev code)
        .uleb128 0x34    # (TAG: DW_TAG_variable)
        .byte   0        # DW_children_no
        .uleb128 0x3     # (DW_AT_name)
        .uleb128 0xe     # (DW_FORM_strp)
        .uleb128 0x3a    # (DW_AT_decl_file)
        .uleb128 0xb     # (DW_FORM_data1)
        .uleb128 0x3b    # (DW_AT_decl_line)
        .uleb128 0x5     # (DW_FORM_data2)
        .uleb128 0x49    # (DW_AT_type)
        .uleb128 0x13    # (DW_FORM_ref4)
        .uleb128 0x1c    # (DW_AT_const_value)
        .uleb128 0xa     # (DW_FORM_block1)
        .byte   0
        .byte   0

so it should take a DW_FORM_block1 encoded DW_AT_const_value.  However, the
code emitted by GCC in debug_info *does not emit* anything in place of that
DW_FORM_block1 ...  Thus the resulting debug section is corrupted.

This happens when emitting debug info for:

static void felem_reduce(felem out, const widefelem in)
{
    static const widelimb two127p15 = (((widelimb) 1) << 127) +
        (((widelimb) 1) << 15);
    static const widelimb two127m71 = (((widelimb) 1) << 127) -
        (((widelimb) 1) << 71);
    static const widelimb two127m71m55 = (((widelimb) 1) << 127) -
        (((widelimb) 1) << 71) - (((widelimb) 1) << 55);

where widelimb is a typedef for uint128_t.  Since the variable is indeed
constant and therefore optimized away, it makes sense to emit a
DW_AT_const_value attribute.  Since the type is uint128_t, it makes sense to
encode the constant value as DW_FORM_block1.  However, the actual encoding is
then simply missing from the output ...

I'll attempt to reproduce this against upstream GCC.