Re: [fpc-devel] Help/Guidance please: Dwarf support for properties
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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Help/Guidance please: Dwarf support for properties
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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Help/Guidance please: Dwarf support for properties
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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Help/Guidance please: Dwarf support for properties
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). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Help/Guidance please: Dwarf support for properties
On 27/04/2024 17:05, Martin Frb via fpc-devel wrote: On 27/04/2024 15:24, Jonas Maebe via fpc-devel wrote: On 27/04/2024 13:45, Martin Frb via fpc-devel wrote: Ok, I would like to start another attempt to support properties when using fpdebug as debugger. I would recommend asking guidance on the DWARF list (dwarf-discuss). Maybe there are already standard-supported constructs to do this. It is not mentioned in the latest draft for dwarf 6. https://snapshots.sourceware.org/dwarfstd/dwarf-spec/latest/ Joost actually checked https://lists.dwarfstd.org/pipermail/dwarf-discuss/2021-May/thread.html https://lists.dwarfstd.org/pipermail/dwarf-discuss/2021-June/thread.html And Joost based his implementation on this. 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?) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Help/Guidance please: Dwarf support for properties
On 27/04/2024 15:24, Jonas Maebe via fpc-devel wrote: On 27/04/2024 13:45, Martin Frb via fpc-devel wrote: Ok, I would like to start another attempt to support properties when using fpdebug as debugger. I would recommend asking guidance on the DWARF list (dwarf-discuss). Maybe there are already standard-supported constructs to do this. It is not mentioned in the latest draft for dwarf 6. https://snapshots.sourceware.org/dwarfstd/dwarf-spec/latest/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Help/Guidance please: Dwarf support for properties
On 27/04/2024 13:45, Martin Frb via fpc-devel wrote: Ok, I would like to start another attempt to support properties when using fpdebug as debugger. I would recommend asking guidance on the DWARF list (dwarf-discuss). Maybe there are already standard-supported constructs to do this. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
