Re: [fpc-devel] Free Pascal for Windows aarch64 Bug Bounties
J. Gareth Moreton via fpc-devel schrieb am Sa., 27. Apr. 2024, 10:00: > You've piqued my interest. I currently only have the ability to develop > on aarch64-linux (Raspberry Pi 400), but I'm curious to know if I can get a > version of Windows to run on it, even if the performance will be very bad. > In a Pi 4 it runs relatively well. I've done it both natively and as a KVM. Check the WoRProject ( https://worproject.com/ ). A Pi 5 would be even better though there you currently might need to use KVM as the native drivers are still a work in progress. > So far I've tried to reproduce the issues on aarch64-linux without any > success. 40203 makes sense because it may be a specific issue with Windows > exception handling, but 40198 is a mystery because it's more closely tied > with code generation. Can you verify that the problem illustrated on 40198 > still occurs on the trunk? (I've confirmed that if there are more than 10 > case statements, the code generator attempts to use a jump table unless > optimisations are turned off) > It's a Windows specific issue, cause the PE format has slightly different relocation requirements than the ELF format. Regards, Sven > ___ 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
[fpc-devel] Help/Guidance please: Dwarf support for properties
Ok, I would like to start another attempt to support properties when using fpdebug as debugger. The idea is to add custom tags in the dwarf info. This can be done by a new option -godwarfporperties Though, it may be better to go with -godwarffpdbg / similar to -godwarfcpp Making it fpdebug specific will allow to add other info, that would benefit debugging Pascal, but isn't in Dwarf... In 2022 Joost did an attempt: https://gitlab.com/freepascal.org/fpc/source/-/compare/main...joost%2Fdwarfproperties?from_project_id=28644964=false I didn't understand the reasons behind (but then I am not familiar with the FPC codebase). I do now get some guesses as to why... - But anyway, I started my own attempt based on that. https://gitlab.com/martin_frb/fpc-src/-/compare/main...martin-dwarf-properties?from_project_id=28644964=false The first problem is getting labels for items that need to be referenced. 2a267440b240be3aa99d0c14fd6c8dcf90a27f99 For procedures this is explained in the first commit => they currently have an (possible intentional) unbalanced dbg_state_writing. Requiring them to have a label, conflicts with that. I welcome feedback on the suggestions in my commit message. 19e6b4fea54b85df1ad8df221947231d01d98bb9 Just completing the above, and write the labels. 959566d705d6a464b3076a97ddaa8213c9d9ec9f Same problem for DW_TAG_MEMBER My "workaround" is certainly wrong. But currently there is no SYM. How can I get labels for it? Such as that they also work, if the field is in the parent, in a diff unit => which on linux requires a global label, since the declaration is NOT copied into the current unit. 50f7d0d53a20cef541f87b474a7b8cc39558808d Write the basic info. Currently only works if the property field/getter is in the same object (or base class), but not if it is in a record belonging to the object. The latter requires the structure address to be also written, and resolving the record to the field... But before I go and spent time on that, I would like to first resolve all the issues that already exist. - Using -godwarffpdbg would also allow for this: https://gitlab.com/martin_frb/fpc-src/-/compare/main...martin-entry-pc?from_project_id=28644964=false Which makes sure there is an address for each of the functions that need to be called. - Test implementation in Lazarus https://gitlab.com/martin_frb/lazarus/-/commits/fpdebug-godwarfproperties properties with getters aren't called yet. It shows the getter, as if it was an event variable. But if the getter has an address, it can be called by adding "()" (and enabling function eval). At least for datatypes supported in function calls. Looking forward to some feedback. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Free Pascal for Windows aarch64 Bug Bounties
I figured that would be the case with the PE format. Fun times ahead! Kit On 27/04/2024 13:06, Sven Barth via fpc-devel wrote: J. Gareth Moreton via fpc-devel schrieb am Sa., 27. Apr. 2024, 10:00: You've piqued my interest. I currently only have the ability to develop on aarch64-linux (Raspberry Pi 400), but I'm curious to know if I can get a version of Windows to run on it, even if the performance will be very bad. In a Pi 4 it runs relatively well. I've done it both natively and as a KVM. Check the WoRProject ( https://worproject.com/ ). A Pi 5 would be even better though there you currently might need to use KVM as the native drivers are still a work in progress. So far I've tried to reproduce the issues on aarch64-linux without any success. 40203 makes sense because it may be a specific issue with Windows exception handling, but 40198 is a mystery because it's more closely tied with code generation. Can you verify that the problem illustrated on 40198 still occurs on the trunk? (I've confirmed that if there are more than 10 case statements, the code generator attempts to use a jump table unless optimisations are turned off) It's a Windows specific issue, cause the PE format has slightly different relocation requirements than the ELF format. Regards, Sven ___ fpc-devel maillist -fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel___ 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 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 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 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 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
