FPC 3.3.1 and before. See also #41019 ## 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.<br/> 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).<br/> 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.