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

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 :

It looks like the right direction. But see my comment on the issue.

It is correct as in that those are the 2 values that need to be adjusted (According to code review). Just the 2nd case should be adjusted by assigning the correct values to the variable "uppercodes"

I will have to setup a quick test.
I had my findings by code-review only.

Ok, I made a merge request (slightly diff from the patch, but to the same effect).
I tested this, and it produces valid dwarf again.

There is the question as to introducing a constant, instead of changing several copies of the same number.
On the other hand it happens once every x years.
And I don't know what the preferred style is.

Could also be
   const   EntryLen = array[Boolean] of integer = (14, 17); and then use a boolean variable instead of "uppercodes".

But that is not part of the issue itself.