http://bugzilla.suse.com/show_bug.cgi?id=936563
http://bugzilla.suse.com/show_bug.cgi?id=936563#c9
--- Comment #9 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.
--
You are receiving this mail because:
You are on the CC list for the bug.