[fpc-devel] Help/Guidance please: Dwarf support for properties

[Martin Frb]

On 27/04/2024 20:29, Jonas Maebe via fpc-devel wrote:
> On 27/04/2024 17:18, Martin Frb via fpc-devel wrote:
>>
>> One of the posts also brings up the idea of avoiding labels (in asm), 
>> and keep track of locations by counting the bytes in the generated 
>> dwarf as part of the compilers work (IMHO duplicate what the asm 
>> already can do?)
>
> That's not the assembler's, but the linker's job. And on macOS, the 
> DWARF info is not processed by the linker and hence can only contain 
> relative offsets (differences between two local labels).

Maybe a miss understanding: storing the difference between 2 local 
labels would be the asm?
But if (e.g. on Linux) it is cross units then its the linker.

There are 2 consideration here.

1)
First, telling the asm to store  ".l99 - .ldebuginfo" or telling the asm 
to store 733 (having done the math already) will result in the same 
dwarf info.
Of course this only works for local labels.

The big question here is, if it is ok to use labels (potentially many 
labels) for this purpose.
 From the mails at the dwarf list, it seems Joost wanted to avoid this, 
but it is not clear why.

Joost then went on, to count the bytes that are added by each bit of 
dwarf info written (same as the asm would do), and therefore be able to 
write the number directly (or in some cases iirc write it later into the 
gap).
That leads to a very big changeset, as the entire dwarf generating code 
needs to do counting.
(And IMHO, that is very easy to accidentally break / and if just one 
very specific dwarf encoding breaks it, it may be months until found)

But, then again I don't know anything about the impact of such amounts 
of additional labels...


2)
At least on Linux, references for dwarf go across compilation units.

On Windows, if "unit1" has "TForm1 = class(TForm)", that leads to *all* 
base classes being encoded into that unit. Almost every unit will 
therefore have a copy of TObject (if it is oop). On Linux, only one unit 
has this.

I must say, I haven't checked how Joost's code deals with that. (and 
mine would probably still need work for that too, but before doing 
anything, I am trying to find out what is ok).
Afaik that is why there is:     tf_dwarf_only_local_labels in 
target_info.flags