Hi Martin, could you tell me if https://gitlab.com/freepascal.org/fpc/source/-/issues/39928#note_1140122898
fixes your troubles? Thanks in advance, Pierre Le 19/10/2022 à 19:47, Martin Frb via fpc-devel a écrit :
Revision: 1b6982107f1ac4b4111e37be0a3649d155a2bc1e Author: florian <flor...@freepascal.org> Date: 10/10/2022 22:45:31 Message: * TDebugInfoDwarf3.appenddef_object should not write an extra finish_entry for objects and C++ classes This adds extra DW_OP_... statements in 2 places In procedure addstringdef(const name: shortstring; chardef: tdef; deref: boolean; lensize: aint); + current_asmdata.asmlists[al_dwarf_info].concat(tai_const.create_8bit(ord(DW_OP_nop))); However it does not increase the byte count "upperopcodes" in the append_entry(DW_TAG_subrange_type,false,[ DW_AT_lower_bound,DW_FORM_udata,1, DW_AT_upper_bound,DW_FORM_block1,upperopcodes ]); Similar in: procedure tdebuginfodwarf3.appenddef_array(list: tasmlist; def: tarraydef); ------------------ I am still puzzled at the effect from what I saw in the data I got from a reporter. He send me an objdump (which failed mid way) <2><2617>: Abbrev Number: 18 (DW_TAG_subrange_type) <2618> DW_AT_lower_bound : 1 <2619> DW_AT_upper_bound : 13 byte block: 97 6 12 28 4 0 30 2f 3 0 38 1c 6 (DW_OP_push_object_address; DW_OP_deref; > <2><2627>: Abbrev Number: 22 (DW_TAG_subprogram) It should be followed by "Abbrev Number; 0" (end of the nested block) Of course FPC would now write 14 bytes (while the header still says 13), bot the 14th byte should be DW_OP_nop = $96 So I am puzzled where the 22 comes from. Though that could be something that objdump did. (I don't have the exe in question / and I haven't reproduced myself) _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
