Debug info for enum types

FPC 3.3.1 and before.

See also #41019 (closed)

1

An enum value's ordinal value appears to be signed for FPC. However debug info does not indicate so. Such an indication might be needed to correctly perform comparison EnumMemerA > EnumMemberB. Dwarf allows to specify a type for the enum.
Specified in Dwarf-3 and higher:

The enumeration type entry may also have a DW_AT_type attribute which refers to the underlying data type used to implement the enumeration.

2

To find the enum-member from the value in an enum-variable it is not needed to know if it is signed or not (afaik).
From Dwarf-2 and higher

Each enumerator entry also has a DW_AT_const_value attribute, whose value is the actual numeric value of the enumerator as represented on the target system.

From as represented on the Target system I would conclude that it is the same bit-sequence as stored in memory (read according to the targets rules big or little endian).

If following that then FPC stores an incorrect value

{$PackEnum 1}
type
  Tfoo = (f1=-1, f2=100);

leads to (3.3.1 / 64 bit Win)

 <1><78c>: Abbrev Number: 5 (DW_TAG_enumeration_type)
    <78d>   DW_AT_name        : Tfoo
    <792>   DW_AT_byte_size   : 1
 <2><793>: Abbrev Number: 6 (DW_TAG_enumerator)
    <794>   DW_AT_name        : f1
    <797>   DW_AT_const_value : 0xffffffff
 <2><79b>: Abbrev Number: 6 (DW_TAG_enumerator)
    <79c>   DW_AT_name        : f2
    <79f>   DW_AT_const_value : 0x64
 <2><7a3>: Abbrev Number: 0

The constant value is encoded using DW_FORM_data_4 4 bytes / 32 bit with leading 1 bits that are not represented in the actual value.

I would think either DW_FORM_data_1 or leading 0. Though leading 0 might interfere with the signed-ness, even though the value is know to have a size of 1 byte, and should probably be sign extended from that.

---

May need testing for gdb/lldb.