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

Jonas Maebe jonas at freepascal.org
Sat Apr 27 22:10:40 CEST 2024


On 27/04/2024 21:40, Martin Frb via fpc-devel wrote:
> 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.

Sure. The current DWARF writer also does this.

>  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)

There's one case in which you would have to do it manually: if you want 
to save those offsets in leb128 encoding. At least on macOS there's no 
support for storing the difference between two labels in s/uleb128 in DWARF.

> 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

Correct.


Jonas



More information about the fpc-devel mailing list