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

Martin Frb lazarus at mfriebe.de
Sun Apr 28 12:36:53 CEST 2024


On 27/04/2024 22:10, Jonas Maebe via fpc-devel wrote:
> On 27/04/2024 21:40, Martin Frb via fpc-devel wrote:
>> 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.
>
> Sure. The current DWARF writer also does this.
>
So on Windows (and presumingly Mac) that will all be local labels.

On Linux (I just checked) the current Dwarf writer generates global 
labels (with relocations).
The change in question would add quite a few more of them. As any field 
or method in a class can be referred to by a property (even from another 
unit (except private), it would need to add a label to each and every 
field and method.
[[ see below ]]


So, if that is OK, then I would appreciate some pointers how I can best 
generate those labels.
Some of the code does not have a TDef - Which is needed for 
"get_def_dwarf_labs()".

Then again, I might have another look at Joost's code and try to 
rebase/fix it for current trunk....

But then before I do, is there any feedback on it?
What would be the requirements to get it accepted?

Would there be preferences between the 2 approaches?

> At least on macOS there's no support for storing the difference 
> between two labels in s/uleb128 in DWARF.

That should be (from dwarf point of view) the same as on Windows? On 
Windows the generated dwarf does only have references within each 
compilation unit.
I don't have a Mac at hand right now, but I assume that an Mac any 
declaration from another unit (such as e.g.  base classes) will have a 
copy written to any unit in which they need to be referenced.


-----------------------
Off topic to properties, but looking at what currently happens on Linux

The compiler is smart enough to only add exported-labels for types in an 
"interface section".

Types private to the unit, well... It seems they were meant to get local 
labels, but do get exported too?
They get (on linux) labels like (on windows that is just .ld20):
     _$UNIT1$_Ld20

And that label is present in the .o file.




More information about the fpc-devel mailing list