[fpc-devel] Attn Florian, commit 1b698210 10/10/2022 22:45:31 breaks DWARF info

[Martin Frb]

Revision: 1b6982107f1ac4b4111e37be0a3649d155a2bc1e
Author: florian <florian at 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)