[fpc-devel] Update on DWARF property spec
I just got an update on the Dwarf mailing list on how the property spec my look. I thought I forward it here, in order to get additional feedback. My initial proposal can be found here: https://dwarfstd.org/issues/240507.1.html My reply is here: https://lists.dwarfstd.org/pipermail/dwarf-discuss/2024-September/002520.html I commented on - properties forwarding to field in record TMyClass = class FData: TMyRecord; property ValA: integer read FData.a; - DW_AT_Type can be optional / same as getter/setter - clarification on function parameters - oxygene different visibility for read/write Forwarded Message Subject: Re: [Dwarf-discuss] Proposal: Add support for "property" with getter/setter (based on Pascal properties) Date: Mon, 30 Sep 2024 10:30:30 -0700 From: Adrian Prantl To: Martin CC: dwarf-disc...@lists.dwarfstd.org, Augusto Noronha , Michael Buch Hello Martin, sorry for the long delay for getting back to you. The DWARF committee was on hiatus over the summer but we're resuming regular meetings now and I would like to prepare this issue for discussion now. I have tried to remove everything from the proposal that could be considered an implementation detail of the Pascal compiler. DWARF tries to be descriptive, and not prescriptive in its approach so I'm intentionally leaving freedom for languages to pick the right representation using the framework specified in the standard. Below is my suggestion of what the wording could look like. The wording I chose would also work with Objective-C and Swift properties. To fully represent Objective-C properties we also need the DW_AT_APPLE_property_attribute extension to encode language-specific flags, but I think I'd fine with just keeping this as an extension for now. Please let me know if I am missing any important use-cases that you could not describe in the Pascal compiler following this specification, if there are any mistakes in it, or if there are Pascal-specific details we should really move into the DWARF spec itself instead of leaving them as an implementation detail to the compiler/debugger. thanks, Adrian PS: One thing I left out is DW_AT_Property_Object. It wasn't clear to me why this wouldn't always be the address of the parent object of the DW_TAG_property. # Proposal to implement "properties" (based on Pascal) ## Background Pascal has a property construct, that allows a "variable like" identifier, which can either point to a field (member variable) or a getter/setter function. ``` TFoo = class FField: integer; function GetProp: integer; procedure SetProp(AVal: Integer); property MyProp: integer read GetProp write SetProp; property MyOtherProp: integer read FField; end; ``` * Properties can exist in a structure, interface, or on a global level. * Properties can be read/write, read only, write only. * Properties can have one or more array like indexes (of any type). ``` function GetProp(AIdx:word; AIdx2: boolean): integer; procedure SetProp(AIdx:word; AIdx2: boolean; AVal: Integer); property MyProp[AIdx:word; AIdx2: boolean]: integer read GetProp write SetProp; ``` * Properties can share a method, and provide an index (constant) to identify which property called the method. ``` function GetProp(AIndex: Integer): integer; procedure SetProp(AIndex: Integer; AValue: integer); property MyProp1: integer index 1 read GetProp write SetProp; property MyProp2: integer index 2 read GetProp write SetProp; ``` * Properties can have a "default" flag, indicating that the array [] access can omit the property name. I.e. accessing "Object[n]" is a shortcut for the default property. (default for non-array properties is being considered for future addition) * Properties can have "default" and "stored" values for streaming (constant or via function). * Properties can be elevated to a higher visibility (private/public) in inherited classes. There may be partial overlaps with properties in Objective-C and C# ### References FreePascal property doc https://www.freepascal.org/docs-html/ref/refse27.html Oxygene https://docs.elementscompiler.com/Oxygene/Members/Properties/ APPLE extension for Objective-C https://github.com/llvm/llvm-project/blob/main/llvm/docs/SourceLevelDebugging.rst#debugging-information-format-1 ## Proposed Changes ### Table 2.1 add `DW_TAG_property`. ### 5.7.6 add the following normative text `DW_TAG_property` Non-normative: Many object-oriented languages like Pascal and Objective-C have properties, which are member functions that syntactically behave like data members of an object. Pascal can also have global properties. A property is represented by a debugging information entry with the tag `DW_TAG_property`. At property entry has a `DW_AT_name` string attribute whose value is the property name. A property entry has a `DW_AT_type` attribute to denote the type of that property. A pr
Re: [fpc-devel] softfloat: sizeOf( floatx80 )
On 28/09/2024 10:56, Karoly Balogh via fpc-devel wrote: Fromt the top of my head, I only know one example of a big endian system which has an 80 bit extended type in hardware, and it's the Motorola 68000 family. Which actually stores exteded in a 96 bit format in memory, with a gap. :) (See: Motorola 68000 Family Reference manual, Page 5-110) Ok, so then on that platform the gap should probably also exist in the record. Well, 1., see above 2., if you _really_ want to have this compatible among all systems, you need to decide on an on-disk format, including actual endianness, then just properly serialize-deserialize it to match that. Yes, that would have to be deserialised to the gap format, for a platform that has the gap. I would assume that e.g. gdb (if it supports the format at all) would expect the gap on that platform. I don't know if floatx80 promises such compatibility. But it would be very useful if it did. No, I don't think promises anything like that. I'd say it is primarily an internal structure, and using it for I/O might simplify your use case, but changing it globally to packed will be a massive performance penalty on some systems where you need this performance the most. So we can't change it globally in the compiler/RTL. Ok, well... Currently it is only needed on Win-64. For FpDebug. So the 64bit debugger can cross debug a 32 bit target and show "extended" values from the 32 bit target. I have test case that will detect if FPC changes anything. If that happens, I will simply have to add a copy of the current working version to FpDebug. Technically, I agree it would then be FpDebug's task to translate the format. But that would require that the format of floatx80 is documented in such a way that it can (and is meant to be) written by 3rd party code. And of course, if I where cross debugging from Intel to M68000 the adaption would certainly be my duty. Maybe the softfloat libraries can provide some routine that takes memory in the native format and store it correctly into the record? On Intel: array[0..9] of byte On M68000: array[0..11] of byte Or a record of the correct size, or As long as it is documented. Or does such a doc already exist? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] softfloat: sizeOf( floatx80 )
On 28/09/2024 09:45, Martin Frb via fpc-devel wrote: On 28/09/2024 09:34, Pierre Muller via fpc-devel wrote: I think that the big endian version (see grep below) would suffer if you would use packed because the high field of size 2, would put the low field of size 8 at offset 2, which would trigger unaligned access to this field. About the big endian issue: That means it is not memory compatible with a native "extended" because it has a gap. So if you load data from a file/stream that has been written with native (gap free) extended, then it wont work. I don't know if floatx80 promises such compatibility. But it would be very useful if it did. On little endian, tests have shown that it can be used that way. Just for my understanding As I haven't really looked deeply into the representation of those numbers. My current understanding starts of with the DWARF spec. That simply specifies - type: float - size (in bytes or bit): ... e.g. 8/64 or 10/80. In addition, now googled, on wikipedia there is only one format for 80bits? (unless I missed something). But it's in a paragraph referring to x86... https://en.wikipedia.org/wiki/Extended_precision#x86_extended_precision_format From that any debugger on any platform seems to be able to read such a float. So I presumed that for a given length there is a standard how the number should be represented in memory? I haven't tested if e.g. gdb would on a big endian be able to read an 80bit float. Or if it would just say that is an invalid size for the platform. But given that floats (like any other data) can be streamed to files and other media, I would expect that the existence does not change by the features of the CPU. Of course the byte order may change. (I don't know if bytes or bits for extended are in a diff order on a big endian? But if they are the reader of a stream would know to fix that). But I wouldn't expect gaps in the data, that is assuming the data can exist. Now all of the above are just conclusions from one rather small starting point. So I may well be wrong. If I am, I would like to know where? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] softfloat: sizeOf( floatx80 )
On 28/09/2024 09:34, Pierre Muller via fpc-devel wrote: I think that the big endian version (see grep below) would suffer if you would use packed because the high field of size 2, would put the low field of size 8 at offset 2, which would trigger unaligned access to this field. For the little endian definition, it doesn't change anything, does it? It's not to important (for my case ). I have a case where the data comes from another process (just 10 bytes, that are an extended in a 32bit process (Win), and get loaded by a 64bit process into the softfloat.) I was comparing; SizeOf(MyVAr) = 10 and that failed. So now I had to hardcode everywhere that a floatx80 can take those 10 bytes. If I had wanted to put that in a generic and specialize with floatx80, double and single, then I had a problem because sizeOf would not work. I don't currently need it as generic. About the big endian issue: That means it is not memory compatible with a native "extended" because it has a gap. So if you load data from a file/stream that has been written with native (gap free) extended, then it wont work. I don't know if floatx80 promises such compatibility. But it would be very useful if it did. On little endian, tests have shown that it can be used that way. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] softfloat: sizeOf( floatx80 )
Is there any indention in floatx80 = record case byte of 1: (low : qword;high : word); // force the record to be aligned like a double // else *_to_double will fail for cpus like sparc // and avoid expensive unpacking/packing operations 2: (dummy : extended); end; NOT being a packed record? If it was packed, it should have the same size as an actual extended: 80 bits / 10 bytes. Possible similar issues for other softfloat types ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] RETRACTED Re: fpc 3.2.3 freezing entire OS / Linux
Sorry, seems the VM itself went bonkers. All fine after a reboot of the guest system. On 17/08/2024 18:27, Martin Frb via fpc-devel wrote: On 17/08/2024 17:25, Martin Frb via fpc-devel wrote: Ok, right now, not sure where to start. I have a modified Lazarus source, that I am trying to build. I tried with -va it stopped a lot faster 90.461] (1) Unitsearch: /home/m/laz/lazgit/components/datetimectrls/design/lib/x86_64-linux/gtk2/LazProjectGroups.pas [90.461] Searching file /home/m/laz/lazgit/components/datetimectrls/design/lib/x86_64-linux/gtk2/LazProjectGroups.pas... not found [90.461] Searching file /home/m/laz/lazgit/components/datetimectrls/design/lib/x86_64-linux/gtk2/lazprojectgroups.pas... not found [90.461] Searching file /home/m/laz/lazgit/components/datetimectrls/design/lib/x86_64-linux/gtk2/LAZPROJECTGROUPS.PAS... not found [90.461] (1) Unitsearch: /home/m/laz/lazgit/components/jcf2/lib/x86_64-linux/LazProjectGroups.ppu [90.461] Searching file /home/m/laz/lazgit/components/jcf2/lib/x86_64-linux/LazProjectGroups.ppu... not found [90.469] Searching file /home/m/laz/lazgit/components/jcf2/lib/x86_64-linux/lazprojectgroups.ppu... not found [90.469] Searching file /home/m/laz/lazgit/components/jcf2/lib/x86_64-linux/LAZPROJECTGROUPS.PPU... not found Error: /home/m/fpc/rel_3.2.3/64/def/bin/ppcx64 can't be executed, error message: Failed to execute "/home/m/fpc/rel_3.2.3/64/def/bin/ppcx64", error code: -9 ___ 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] fpc 3.2.3 freezing entire OS / Linux
On 17/08/2024 17:25, Martin Frb via fpc-devel wrote: Ok, right now, not sure where to start. I have a modified Lazarus source, that I am trying to build. I tried with -va it stopped a lot faster 90.461] (1) Unitsearch: /home/m/laz/lazgit/components/datetimectrls/design/lib/x86_64-linux/gtk2/LazProjectGroups.pas [90.461] Searching file /home/m/laz/lazgit/components/datetimectrls/design/lib/x86_64-linux/gtk2/LazProjectGroups.pas... not found [90.461] Searching file /home/m/laz/lazgit/components/datetimectrls/design/lib/x86_64-linux/gtk2/lazprojectgroups.pas... not found [90.461] Searching file /home/m/laz/lazgit/components/datetimectrls/design/lib/x86_64-linux/gtk2/LAZPROJECTGROUPS.PAS... not found [90.461] (1) Unitsearch: /home/m/laz/lazgit/components/jcf2/lib/x86_64-linux/LazProjectGroups.ppu [90.461] Searching file /home/m/laz/lazgit/components/jcf2/lib/x86_64-linux/LazProjectGroups.ppu... not found [90.469] Searching file /home/m/laz/lazgit/components/jcf2/lib/x86_64-linux/lazprojectgroups.ppu... not found [90.469] Searching file /home/m/laz/lazgit/components/jcf2/lib/x86_64-linux/LAZPROJECTGROUPS.PPU... not found Error: /home/m/fpc/rel_3.2.3/64/def/bin/ppcx64 can't be executed, error message: Failed to execute "/home/m/fpc/rel_3.2.3/64/def/bin/ppcx64", error code: -9 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] fpc 3.2.3 freezing entire OS / Linux
Ok, right now, not sure where to start. I have a modified Lazarus source, that I am trying to build. Only, when FPC tries to compile it, it never returns. And freezes my Fedora (in a Virtualbox). It will eventually (after an hour or longer) be killed by the OS. Which at least at one time reported that the compiler used up almost all memory. (there was no report of a stack overflow, and that wouldn't take that long. Given the time it takes, I thing it fragments memory while being in an endless loop) Since it freezes the OS too, I have hardly anyway of debugging it. (maybe if I can see where it gets mem from the OS / but I haven't currently gotten fpc set up for being debugged...) If I observed it correctly, one of the following options has an impact (because I think - but need to doublecheck later) that without them, the build worked) -gv -gw3 -CR-r-i-o-t- -Sa- -Si- -Se15 -ve -vw -vn -vi -O-1 -CX And unfortunately that is all I have so far. It seems that all files get compiled, so it might be something at the end... Which may also mean, it could be some other app called by fpc (my fpcres may be outdated / since I at some point copied it into /usr/local/bin) Also, I have previously compiled with the exact same settings. SO all that changed are a few Lazarus sources, and one res file. I did change a resource. The res file was rebuild on Windows, and on Linux only the res file is used (all png images). But a standalone project can use the new res file (at least just the one, not tried combining it with others that the IDE may have). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Maybe missing assigned check? TBasicActionLink.Update
Other functions of TBasicActionLink have checks like if FAction <> nil then But "Update" does not. Is that intended? Or shall I bug report it? function TBasicActionLink.Update: Boolean; begin Result := FAction.Update; end; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] soft-fpu
On 10/07/2024 23:55, Sven Barth via fpc-devel wrote: The SoftFpu unit is only intended for use by the compiler. If you want to use 80-bit floating point yourself you need to use ufloat80 and sfpux80 (the later wraps the same include files as SoftFpu, but for use by the user). Thanks. Now FpDebug can show the fpu st0..st7 registers. I guess on Windows 64 they aren't used, except when cross debugging a 32bit target. => still needs work, as currently the value is handled as double in the IDE (less precision)___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] soft-fpu
Any hints on using unit SoftFpu? (or any alternative) I have an 80 bit float (from an external source) that needs to be converted to double. But if I do uses softfpu, ufloatx80 then I get Error: Multiple defined symbol "INT32_TO_FLOAT64" and many more... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unnoticed bug report
On 28/06/2024 09:44, Werner Pamler via fpc-devel wrote: I having the same experience as Laz-dev: I see a report which looks interesting, but cannot address it at the moment. Not sure whether I really can fix the issue I do not assign it to myself at this moment. And later, when I could have a closer look, that report has scrolled down the list and is no longer seen readily... There are 2 options (that I am aware of). 1) Make a todo for that issue. Unfortunately the Gitlab Todo list floods itself with other stuff, so you need to constantly clean it. 2) Add a "reaction" (i.e. a thumbs up, or any other you can find in the list. The issue search allows to search for "My reaction". So reactions can be your "watchlist". (you need to know which reaction you used) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] DWARF proposal - review (for properties) - question on attributes (stored/default)
https://lists.dwarfstd.org/pipermail/dwarf-discuss/2024-May/002424.html While reviewing https://lists.dwarfstd.org/pipermail/dwarf-discuss/2024-June/002451.html https://lists.dwarfstd.org/pipermail/dwarf-discuss/2024-June/002462.html I got thinking, are the "stored" and "default" (default for streaming) strictly bound to properties? Or would it be more sensible (in case they are needed at all) to make them a separate feature, which could include other vars/types? Do any other vars have typeinfo or attributes that could in a similar manner be of interest during debugging? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] DWARF-4 / line info / Re: Freeze of fixes for 3.2.4 by 9th June
On 06/06/2024 16:50, Martin Frb via fpc-devel wrote: On 02/06/2024 22:28, Florian Klämpfl via fpc-devel wrote: To get finally forward with the 3.2.4 release, fixes will be frozen by 9th June, so if there are some last second cherry picks needed, now it’s time to speak up :) Has the line info field for Dwarf 4 been merged? https://lists.freepascal.org/pipermail/fpc-devel/2024-May/045658.html Got the commit: b313a66a47822b0648e25f49ee60ec1719d1443e * * correct Dwarf-4 line info header as noted by Martin on the mailing list ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] DWARF-4 / line info / Re: Freeze of fixes for 3.2.4 by 9th June
On 02/06/2024 22:28, Florian Klämpfl via fpc-devel wrote: To get finally forward with the 3.2.4 release, fixes will be frozen by 9th June, so if there are some last second cherry picks needed, now it’s time to speak up :) Has the line info field for Dwarf 4 been merged? https://lists.freepascal.org/pipermail/fpc-devel/2024-May/045658.html ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Peephole issue in 3.2.3
On 02/06/2024 21:06, J. Gareth Moreton via fpc-devel wrote: I admit I'm not overly sure how to handle Thaddy sometimes: "They fixed it in the wrong way. It is fixed in a way to solve a single - rare - problem by an OP that seems to have more infuence than me and the fixer(s) would not listen." Not sure what problem he's referring to exactly. Hopefully not my aforementioned commit, because I think making sure the flag register is properly allocated so the peephole optimizer can make the correct informed choices is pretty important! Thaddy is talking about another issue, to which he supplied a link. No idea why (or if) he thought they were related. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Peephole issue in 3.2.3
While not sure how 3.2.4 preparation are going, nor what is still outstanding for merging, I just wanted to quickly check if the following is know (and hopefully making the list) https://forum.lazarus.freepascal.org/index.php/topic,67448.0.html From what I can tell - present in today's 3.2.3 - probably peephole Merely from the commit message, possibly https://gitlab.com/freepascal.org/fpc/source/-/commit/6f24c8b4efccea67d092062009f413cc789a052c ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Potentially wrong line info with dwarf 4
On 23/05/2024 22:55, Florian Klämpfl via fpc-devel wrote: On 23.05.24 14:51, Martin Frb via fpc-devel wrote: If I am not missing any detail Using -gw 4 it seems fpc writes the same header for line info as it does for dwarf 3. However, when the line info version is set to 4 (at least if all units are dwarf 4 / if some are dwarf 3 this may not be the case) Dwarf 4 has a new field in the header, and that is not written. objdump in this case delivers trash for the filenames (as they are not in the correct location) Afaik, the line info version can be set to 3, even if other dwarf info is version 4 I fixed the header. This was an easier one :) Which versions of Fpc will that apply? 3.3.1 and up and/or also 3.2.3? Did 3.2.2 have -gw4? I ask because FpDebug will look at the producer to decide if it should read the broken info. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Potentially wrong line info with dwarf 4
If I am not missing any detail Using -gw 4 it seems fpc writes the same header for line info as it does for dwarf 3. However, when the line info version is set to 4 (at least if all units are dwarf 4 / if some are dwarf 3 this may not be the case) Dwarf 4 has a new field in the header, and that is not written. objdump in this case delivers trash for the filenames (as they are not in the correct location) Afaik, the line info version can be set to 3, even if other dwarf info is version 4 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dwarf Standard - implementing...
Anyone any feedback, please?
Or, who would be knowledgeable, and might at least tell me when there
might be time, if too busy right now?
On 17/05/2024 13:49, Martin Frb wrote:
On 09/05/2024 19:53, Martin Frb via fpc-devel wrote:
It's now an issue for the Dwarf standard.
https://dwarfstd.org/issues/240507.1.html
Looking at the time other proposals have taken, I think it is
reasonable to implement properties as custom extension now. And then
later make any amendments (best case, just change the numeric
constants for the DW_TAG/_AT... ).
I have done some experiments on Joost's work. But I now reached the
point were I do need feedback and help:
https://gitlab.com/martin_frb/fpc-src/-/compare/main...martin-dwarf-prop-2?from_project_id=28644964&straight=false
Joost's code had some of the "tai" sizes hard-coded in dbgdwarf.pas. I
moved that into each of the "tai" classes.
https://gitlab.com/freepascal.org/fpc/source/-/commit/6623ccd6245bb0b8d2d46453ac680c18d6c6aad1#1666e6c01f5086b3630dcd10a1b24557a1c178f6_2741_2831
begin
{ write dummy for now }
AddConstToAbbrev(ord(DW_FORM_string));
append_to_al_dwarf_info(tai_string.create(''),1);
Joost's code did write labels to the "tai" list, where the location of
the label was unknown, and later
See "|TPendingOffsetConst" in
|https://gitlab.com/freepascal.org/fpc/source/-/commit/6623ccd6245bb0b8d2d46453ac680c18d6c6aad1#1666e6c01f5086b3630dcd10a1b24557a1c178f6
I tried to use (local) labels for that. This only happens if the Dwarf
target DIE is in the same CU.
However, I encountered some issues
- On Linux, I think I get global labels.
- I needed labels for TSym
- for code like
TFoo = record a: integer; property b: integer read a; end;
TBar = type TFoo;
TBar is written using the same symbol (same instance). So I can't
get 2 labels (currently the same label gets written twice, leading to
an error)
So what is the best way to proceed there?
I also did not yet manage to create a link to the static variable that
is written for static fields, when it is referred by a class property.
But maybe that can be done, when static fields are moved inside the
class DWARF-5 "5.7.7 Class Variable Entries" allows
DW_TAG_Variable in a structure.
Btw, while writing the dwarf, is there a way to tell from the data, if
a property is written because setter/getter are declared here, or
because it changes only visibility?
Other comments/suggestions?
A lazarus proof of concept counter part.
(To view properties, each watch still must have "function calling"
enabled)
https://gitlab.com/martin_frb/lazarus
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Dwarf Standard - implementing...
On 09/05/2024 19:53, Martin Frb via fpc-devel wrote:
It's now an issue for the Dwarf standard.
https://dwarfstd.org/issues/240507.1.html
Looking at the time other proposals have taken, I think it is reasonable
to implement properties as custom extension now. And then later make any
amendments (best case, just change the numeric constants for the
DW_TAG/_AT... ).
I have done some experiments on Joost's work. But I now reached the
point were I do need feedback and help:
https://gitlab.com/martin_frb/fpc-src/-/compare/main...martin-dwarf-prop-2?from_project_id=28644964&straight=false
Joost's code had some of the "tai" sizes hard-coded in dbgdwarf.pas. I
moved that into each of the "tai" classes.
https://gitlab.com/freepascal.org/fpc/source/-/commit/6623ccd6245bb0b8d2d46453ac680c18d6c6aad1#1666e6c01f5086b3630dcd10a1b24557a1c178f6_2741_2831
begin
{ write dummy for now }
AddConstToAbbrev(ord(DW_FORM_string));
append_to_al_dwarf_info(tai_string.create(''),1);
Joost's code did write labels to the "tai" list, where the location of
the label was unknown, and later
See "|TPendingOffsetConst" in
|https://gitlab.com/freepascal.org/fpc/source/-/commit/6623ccd6245bb0b8d2d46453ac680c18d6c6aad1#1666e6c01f5086b3630dcd10a1b24557a1c178f6
I tried to use (local) labels for that. This only happens if the Dwarf
target DIE is in the same CU.
However, I encountered some issues
- On Linux, I think I get global labels.
- I needed labels for TSym
- for code like
TFoo = record a: integer; property b: integer read a; end;
TBar = type TFoo;
TBar is written using the same symbol (same instance). So I can't get
2 labels (currently the same label gets written twice, leading to an error)
So what is the best way to proceed there?
I also did not yet manage to create a link to the static variable that
is written for static fields, when it is referred by a class property.
But maybe that can be done, when static fields are moved inside the
class DWARF-5 "5.7.7 Class Variable Entries" allows DW_TAG_Variable
in a structure.
Btw, while writing the dwarf, is there a way to tell from the data, if a
property is written because setter/getter are declared here, or because
it changes only visibility?
Other comments/suggestions?
A lazarus proof of concept counter part.
(To view properties, each watch still must have "function calling" enabled)
https://gitlab.com/martin_frb/lazarus___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] class property - should this work - static field in nested field
The below fails to compile. However "b" is a class var. The fact that it is reached via a normal field, does not change that. The address/value of TBar.f.b can be known without on instance of TBar required. Mind, this is a theoretical question, I don't actually need it, just came across the idea and wanted to know. program Project1; type TFoo = object a: integer; class var b: integer; end; TBar = class f: TFoo; class property fb: integer read f.b; // Error: Illegal symbol for property access end; begin end. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dwarf Standard - support for properties
It's now an issue for the Dwarf standard. https://dwarfstd.org/issues/240507.1.html ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] {$i ascdef.inc} / stdcall
Maybe of interest?
The include file {$i ascdef.inc} is used from unit Windows with
{$calling stdcall}
in effect.
Most functions in it therefore don't have "stdcall". But some do. Is
that known/wanted/...?
Similar in some other includes.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] apple properties // Re: Help/Guidance please: Dwarf support for properties
On 03/05/2024 14:17, Sven Barth via fpc-devel wrote: Martin Frb via fpc-devel schrieb am Fr., 3. Mai 2024, 12:13: In case it goes ahead, I am trying to thing of what would be needed Can anyone think of any feature for Pascal properties that is not covered by the below? A property can be marked "default". Currently only array properties, but there is still the idea to implement "hoisting" of sub members through single properties. Right. I will add a "default" flag. Out of interest (I recall having seen the discussion, but I don't recall the details), how would that be accessed? a := MyObj; // will a be assigned the object or the default properties value? Will that also mean multiple default properties, if the index signature differs? Properties of type interface or class can have an "implements" clause that redirects the implementation of an interface implemented by the class (note: class type properties are not yet supported by FPC, but are on the ToDo list for Delphi compatibility). Right. Is that relevant for the debugger though? Or would that be the other way round? I.e. if we implemented debug info for interfaces, then an interface would in the debug info be a structure with lots of functions. Those functions then point to the correct functions in the object. And through the self param, would reveal the object, or in this case the "implements" interface as object (allowing the debugger to forward resolve). Actually, I don't think that the class debug info even includes which interfaces the class implements? The Borland extension seems to have had it: https://github.com/llvm-mirror/llvm/blob/master/include/llvm/BinaryFormat/Dwarf.def#L390 Oxygene introduced per setter/getter visibility and since I had need of this here and then in the past I might still be inclined to implement that in the future, so this might not only be for C# then. Good to know, I will amend that. - I was also thinking if it might help to have a link to an inherited property, if only visibility is changed. But that does not exist for functions either (though actually indirectly yes, through the vmt pointer). That way the debugger could use that to avoid double listing it. E.g. currently there is already the problem that with "strict private" (or private across units) an object can have several fields "MyField". Of the same or different type. (which I still haven't 100% dealt with in fpdebug). With fields though, they are always different. With properties they may be a newly introduced, or a visibility change. But then the absence of any setter/getter would indicate that too.___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] apple properties // Re: Help/Guidance please: Dwarf support for properties
On 02/05/2024 20:59, Jonas Maebe via fpc-devel wrote: --- I don't have background on the Apple properties. It's not Apple, but Objective-C. Does FPC create such Objective-C code / properties? If yes, how does it decide on how to translate "property Foo..."? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] apple properties // Re: Help/Guidance please: Dwarf support for properties
In case it goes ahead, I am trying to thing of what would be needed Can anyone think of any feature for Pascal properties that is not covered by the below? # Proposal to implement "properties" for Pascal ## Background Pascal has a property construct, that allows a "variable like" identifier, which can either point to a field (member variable) or a getter/setter function. They can be read/write, read only, write only. TFoo = class FField: integer; function GetProp: integer; procedure SetProp(AVal: Integer); property MyProp: integer read GetProp write SetProp; property MyOtherProp: integer read FField; end; Properties can exist in a structure, interface, or on a global level. Properties can have one or more array like indexes. TFoo = class function GetProp(AIdx:word; AIdx2: boolean): integer; procedure SetProp(AIdx:word; AIdx2: boolean; AVal: Integer); property MyProp[AIdx:word; AIdx2: boolean]: integer read GetProp write SetProp; end; Properties can share a method, and provide an index (constant) to identify which property called the method. TFoo = class function GetProp(AIndex: Integer): integer; procedure SetProp(AIndex: Integer; AValue: integer); property MyProp1: integer index 1 read GetProp write SetProp; property MyProp2: integer index 2 read GetProp write SetProp; end; Properties can be streamed and therefore can have a default value (constant or via function). They can also have a "stored" value (function) indicating if they need to be stored in the stream. Properties can be elevated to a higher visibility (private/public) in inherited classes. There may be partial overlaps with properties in Objective-C and C# ## Proposed Changes Introducing a new tag DW_TAG_PROPERTY or DW_TAG_PROPERTY_PASCAL This tag can occur anywhere where DW_TAG_MEMBER can occur. It can also occur on a global scope. It can have DW_AT_NAME DW_AT_TYPE DW_AT_ACCESSIBILITY DW_AT_decl_column, DW_AT_decl_file and DW_AT_decl_line. It can then contain any of DW_TAG_PROPERTY_SETTER DW_TAG_PROPERTY_READER DW_TAG_PROPERTY_DEFAULT DW_TAG_PROPERTY_STORED Each of them can have DW_AT_PROPERTY_FORWARD reference/constant refernce to the field or function DW_AT_PROPERTY_OBJECT reference/expression/constant the object on which the value is stored (value for DW_OP_push_object_address) can be omitted for inherited classes, if it computes to the same as the current class A getter (also "default" and "stored" should be a function returning the same type as the property. It should either take no arguments or only DW_AT_object_pointer A setter should be a procedure, it should take optional DW_AT_object_pointer and one argument of the same type as the property. Instead of having attributes grouped in DW_TAG_PROPERTY_SETTER/... all attribute could exist top level, in 4 versions. That would be shorter if no object needs to be specified. But it is less flexible for later additions. For indexed properties the DW_TAG_PROPERTY also has DW_TAG_PROPERTY_INDEX_LIST containing one or more DW_TAG_PROPERTY_INDEX DW_AT_NAME DW_AT_TYPE DW_AT_VALUE reference or constant or expression (returning value) DW_AT_IS_PROPERTY_VALUE flag DW_AT_NAME and DW_AT_TYPE can be optional. They can be gotten from the linked procedure DW_AT_VALUE is optional. It is used when properties share a getter. DW_AT_IS_PROPERTY_VALUE is optional. It can be used to specify the position of the "assigned value" in a setter. If not specified the assigned value will be passed as the last parametr. To change visibility of an inherited property, DW_TAG_PROPERTY DW_AT_NAME DW_AT_ACCESSIBILITY OFF TOPIC: For C# it may be of interest to allow DW_TAG_PROPERTY_SETTER/... to have their own DW_AT_ACCESSIBILITY For C# it may be of interest to allow an inlined function declaration instead of DW_AT_PROPERTY_VALUE ## References FreePascal property doc https://www.freepascal.org/docs-html/ref/refse27.html APPLE extension for Objective-C https://github.com/llvm/llvm-project/blob/main/llvm/docs/SourceLevelDebugging.rst#debugging-information-format-1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] apple properties // Re: Help/Guidance please: Dwarf support for properties
On 02/05/2024 20:59, Jonas Maebe via fpc-devel wrote: --- I don't have background on the Apple properties. It's not Apple, but Objective-C. property goes from the member to the property strikes me as odd. (first example of dwarf) It indicates, that the property is only meant to be found when starting at the member? Objective-C also knows the concept of "computed properties", which are not tied to a particular field. I don't immediately see how the proposal deals/would deal with that. Ok, I don't know how to read that, but potentially many fields could link to the same property. Do those properties need a field at all? Also the Apple spec uses strings (names) to refer to the getter/setter. I don't know if there is a particular underlying need. It's more costly than a reference. Also It gets problematic if the getter is in an embedded record, or if there are overloaded functions, It doesn't use a symbol name, but a selector name. Objective-C method dispatching mostly does not happen using a VMT, but by looking up a (hash of a) selector in a table. "Calling a method" is called "sending a message to" in Objective-C lingo; it's also how it can fairly transparently support working with remote objects. ok. Explains maybe half... I am not immediately sure if dwarf has anything to describe dispatching. Or if this is just left for the debugger to know. Which is ok, with custom tags that are for Objective-C only. I don't know if that table is precomputed / I.e. get completely created at compile time => in which case the location of the looked up hash would be known in the table, and the address of the method could be gotten via a dwarf expression? The other part that I really don't understand is, why you find the property from the field, and not the other way round (above)? Does that mean the code/user would not start with "object.my_property" but rather do "object.field as property"? I am trying to understand if there is any common ground with properties in Pascal. I've ask if they (dwarf makers) see potential for our properties https://lists.dwarfstd.org/pipermail/dwarf-discuss/2024-May/thread.html So, I am trying to figure out were those Apple tags fit into it, and how/if I treat them in that discussion. (the Borland ones, have no docs to be found) However from what I have seen so far, I do think there are fundamental differences. Pascal properties should have - the property as a declaration that is a start point (except for being owned by a class / but also exists without) - links to other entities starting at the property (or no links, and duplication of accessor declarations) Maybe there is still stuff that could be proposed as share-able? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] apple properties // Re: Help/Guidance please: Dwarf support for properties
https://github.com/llvm/llvm-project/blob/main/llvm/docs/SourceLevelDebugging.rst#debugging-information-format-1 Objective C properties exist separately from class members. A property can be defined only by "setter" and "getter" selectors, and be calculated anew on each access. Or a property can just be a direct access to some declared ivar. I don't know if in Apple terms "ivar" has any special meaning? Nor if there is more to "calculated anew on each access"? --- I don't have background on the Apple properties. But the fact that the link between a "field" (tag_member) and the property goes from the member to the property strikes me as odd. (first example of dwarf) It indicates, that the property is only meant to be found when starting at the member? For FPC properties that is the other way round. The property would have to point to the field. (or function) Also the Apple spec uses strings (names) to refer to the getter/setter. I don't know if there is a particular underlying need. It's more costly than a reference. Also It gets problematic if the getter is in an embedded record, or if there are overloaded functions, - There do exist Borland properties https://android.googlesource.com/platform//prebuilts/clang/host/linux-x86/+/b669748458572622ed716407611633c5415da25c/clang-r416183d/include/llvm/BinaryFormat/Dwarf.def But I could not find any details at all ___ 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 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 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: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
[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&straight=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&straight=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&straight=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] wrong result for abs(low(int64))
On 04/04/2024 16:39, J. Gareth Moreton via fpc-devel wrote: Essentially, an arithmetic overflow is happening. Since the largest Int64 possible is 9,223,372,036,853,775,807, going one above that (the result to abs(low(int64))) wraps back around to -9,223,372,036,853,775,808. Internally, you can think about negating (positing?) a negative number as inverting the bits and then adding one (aka. two's complement), so low(int64) is 1000...000, which inverted becomes 0111...111, and then adding one results in 1000...000 again. I got that bit... Initially I was surprised to find "abs" to return a signed number. After all, it will never be negative. But, in the meantime I recalled that unsigned numbers will cause other issues when used in expressions. "abs(-1)-2" would behave different. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] wrong result for abs(low(int64))
The below writes: -9223372036854775808 Shouldn't absolute return a positive number? program Project1; begin writeln( abs(low(int64)) ); end. Seems writeln( abs(low(longint)) ); also returns negative... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc 3.3.1 fails in fpjwarsa
On 20/03/2024 10:14, Michael Van Canneyt via fpc-devel wrote: I just did the same for 55 platforms (cross-compile), on ubuntu. All work without errors ? Apologies, probably my fault. I export the sources from git before build, but did not remove old files. Starting without any old files in the sources, and it works. Thanks for the feedback. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] fpc 3.3.1 fails in fpjwarsa
Older Ubuntu, trying to update (starting compiler is 3.2.2) make clean make all OPT=" -O-1 -gw3 " make install INSTALL_PREFIX=/home/m/fpc/ Compiling ./fcl-web/src/fcm/fpfcmstrings.pp Writing Resource String Table file: fpfcmstrings.rsj Compiling ./fcl-web/src/jwt/fpjwarsa.pp fpjwarsa.pp(21,35) Error: Identifier not found "TJWTSigner" fpjwarsa.pp(21,35) Error: Class type expected, but got "" fpjwarsa.pp(25,64) Error: Identifier not found "TJWTKey" fpjwarsa.pp(26,62) Error: Identifier not found "TJWTKey" fpjwarsa.pp(23,20) Error: There is no method in an ancestor class to be overridden: "class AlgorithmName:System.AnsiString;" fpjwarsa.pp(25,14) Error: There is no method in an ancestor class to be overridden: "CreateSignature(TJWT;):System.AnsiString;" fpjwarsa.pp(26,14) Error: There is no method in an ancestor class to be overridden: "Verify(const AnsiString;):System.Boolean;" fpjwarsa.pp(56,38) Error: Identifier not found "TJWTSigner" fpjwarsa.pp(56,38) Error: Class type expected, but got "" fpjwarsa.pp(60,64) Error: Identifier not found "TJWTKey" fpjwarsa.pp(61,62) Error: Identifier not found "TJWTKey" fpjwarsa.pp(58,20) Error: There is no method in an ancestor class to be overridden: "class AlgorithmName:System.AnsiString;" fpjwarsa.pp(60,14) Error: There is no method in an ancestor class to be overridden: "CreateSignature(TJWT;):System.AnsiString;" fpjwarsa.pp(61,14) Error: There is no method in an ancestor class to be overridden: "Verify(const AnsiString;):System.Boolean;" fpjwarsa.pp(89,1) Fatal: There were 14 errors compiling module, stopping Fatal: Compilation aborted The installer encountered the following error: Compilation of "BuildUnit_fcl_web.pp" failed $00542579 $0054C7E2 $0054B87E $0054CADB $0054FEAA $00540F3B $005415C0 $0047868F $004A5AF9 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Failing Lazarus Codetools Pas2JS-related tests - again
On 19/03/2024 15:41, Mattias Gaertner via fpc-devel wrote: On 19.03.24 14:58, Maxim Ganetsky via fpc-devel wrote: [...] #7 944.7 fpmake.pp(228,5) Error: Identifier not found "T" Ah, you are using fpc 3.3.1 to compile it. Fixed. But I get strange linker errors compiling webidl2pas: (9015) Linking bin/x86_64-linux/webidl2pas /usr/bin/ld.bfd: /path/compiler/utils/pas2js/units/x86_64-linux/webidl2pas.o:(.fpc.n_links+0x50): undefined reference to `DEBUGSTART_$CUSTAPP' /usr/bin/ld.bfd: /path/compiler/utils/pas2js/units/x86_64-linux/webidl2pas.o:(.fpc.n_links+0x58): undefined reference to `DEBUGEND_$CUSTAPP' It compiles with the ppu files of fpc 3.3.1 and 3.2.2 tough, but not with the sources ... I don't know if it applies. But I have in some cases seen similar linking issues, if parts of the code were compiled with DWARF-2 and other parts with DWARF-3 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Question about "Default()"
https://www.freepascal.org/docs-html/rtl/system/default.html Default is a compiler intrinsic: it returns for every type T a default value. In essence, this is a block of memory that is zeroed out. It can be used to correctly initialize any type, and more importantly, a managed type. It also works using a generic type template. But zero isn't always a valid value => so how can it be used to initialize a type where that is invalid. The below will runtime error "invalid enum value". (And also, in the past, I saw it pointed out countless times, that setting an enum to an ordinal value that is not matching any of its members does not have a defined behaviour). So is that a bug in Default? Or is the documentation wrong "any type"? (it contradicts itself anyway "zeroed" <> "any type") Or ...? program Project1; type //tt = 3..5; tt = (e1=3, e2=5,e3=7); var a: tt; begin a := Default(tt); writeln(a); readln; end. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Missing documentation for changes in 3.3.1 - visibility of class fields
The code below (avail as download, wrongly reported at
https://gitlab.com/freepascal.org/fpc/source/-/issues/40634#note_1777253148
=> gen331_b.zip )
compiles in in 3.2.3, but not in 3.3.1
As for as I am concerned 3.3.1 is right. But should that change be
mentioned on the user changes
https://wiki.freepascal.org/User_Changes_Trunk ?
---
program class_nest;
{$mode ObjFPC}{$H+}
uses unit1;
type
TDataPointDistanceTool = class(TDataPointTool) // not inheriting
from the nested class
strict protected
function FindRef(ADest: TDataPointTool.TPointRef): Boolean;
end;
function TDataPointDistanceTool.FindRef(ADest:
TDataPointTool.TPointRef): Boolean;
begin
ADest.FGraphPos := 1;
end;
begin
end.
---
unit Unit1;
{$mode ObjFPC}{$H+}
interface
uses
Classes, SysUtils;
type
TDataPointTool = class
public
type
TPointRef = class
private
protected
FGraphPos: integer; // It is protected
end;
end;
implementation
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Exact rules for "strict protected"
https://www.freepascal.org/docs-html/ref/refse35.html Strict Protected Is the same as Protected, except that the members of a Protected section are also accessible to other classes implemented in the same unit. Strict protected members are only visible to descendent classes, not to other classes in the same unit. In the below TSubFoo can see the strict proctected TTest. So therefore TSubFoo does not count as "not to other classes in the same unit." Well, it is another class, but it is within the class TFoo. TSubBar is also another class, but it is within TBar. And for TBar we have "only visible to descendent classes" => TBar should see TTest. And since TSubBar is in TBar? So the below code have that error, or is it a bug? An if it should, what is the correct exact description of "Strict protected"? program Project1; type TFoo = class strict protected type TTest = record end; private type TSubFoo = class a: TTest; end; end; TBar = class(TFoo) private type TSubBar = class a: TTest; // project1.lpr(15,10) Error: Identifier not found "TTest" end; end; begin end. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Default-max-precision for different float types?
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40768 Are there any defaults, with which precision each float type (single/double/extended) should be printed? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] debug info and TAlphaColor = Cardinal;
The below leads to debug info reporting TAlphaColor as Cardinal. Maybe it could be changed (like TColor is a distinct type)? unit System.UITypes; Type ... TAlphaColor = Cardinal; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] inc(QWORD, BYTE) -> range check
https://www.freepascal.org/docs-html/rtl/system/inc.html - says it operates on pointers - also gives examples for unsigned types such as word But can it be used to increment a QWORD? Inc(FAddress, (Opcode div FOwner.FLineInfo.LineRange) * FOwner.FLineInfo.MinimumInstructionLength); FAddress: QWord = $02B6 All values in the expression are of type Byte. Though the question to ask may be what the result is cast too I know the result of the expression is 0 (zero). From the assembler I can see that I passed the div and the multiplication. And then I got 000100CBEC93 48B8FF7F mov rax,$7FFF 000100CBEC9D 4839C2 cmp rdx,rax 000100CBECA0 7605 jbe +$05 # $000100CBECA7 NEXTLINE+1815 fpdbgdwarfdataclasses.pas:4556 000100CBECA2 E8998535FF call -$00CA7A67 # $000100017240 $fpc_rangeerror system.inc:801 which calls range check. For all I can tell it checks the value of FAddress. But why does it check it against High(Int64) ? It is a QWord. FPC 3.2.3 from Dec 2023 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Modifiers...
https://www.freepascal.org/docs-html/ref/refsu3.html Is this list complete/correct? 1) It lists bitpacked, but program foo; var bitpacked: integer; begin end; gives an error. I thought modifiers can be used as var names? 2) Is there, or has there once been? (found in the synedit highlighter) final automated optional 3) Not on the list, but suspected the should? Some are on https://www.freepascal.org/docs-html/ref/refse100.html sealed inline mwpascal noinline weakexternal compilerproc vectorcall ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] defines by the compiler... / linux, LIBC, SysCall
On 11/01/2024 17:30, Marco van de Voort via fpc-devel wrote:
Let me state it more clearly:
The point is that given a precompiled Linux RTL, to my best knowledge
you can't test any define outside the FPC build environment to see if
the RTL was compiled with FPC_USE_LIBC or not. Maybe there is some
workaround testing for some symbol inside the system unit with{$if
defined(symbol}, but there is no supported global define to test.
Ok, kind of expected that
Targets that enable libc by default (darwin, sunos and openbsd
apparently) by default make this work by locally enabling
FPC_USE_LIBC, usually both in rtl/$target or by other hacks in various
packages/ dirs for shared code, and simply not providing any
alternative in the target specific code.
And to my best knowledge the "LIBC" in the extradefines of Slowaris
(below) means zip, nada, zilch. It is an artifact of 1.0.x times,
which is so old EVEN Lazarus doesn't support it :-)
Ok. ...
Now what I was hoping for, but
- Darwin isn't a problem. As I test for that anyway.
- I can add {$IFDEF SUNOS} too
- Not sure which others...
Sadly however the list can change. So without "LIBC" or other such
define, this is going to be tricky
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] defines by the compiler... / linux, LIBC, SysCall
On 11/01/2024 16:34, Marco van de Voort via fpc-devel wrote:
Op 11-1-2024 om 15:48 schreef Martin Frb via fpc-devel:
- Can (on any linux/unix) "uses SysCall" be compiled (without error)
You can test that yourself on a Linux system by compiling a cycle with
-dFPC_USE_LIBC and then compiling a test program (without defines)
Since there was a bugfix necessary, I assume not.
Not necessary. (as far as I understand the comments that had been made
already)
-dFPC_USE_LIBC would not change the os target to sunos. And therefore
FPC would not look at the tsysteminfo containing
extradefines : 'UNIX;LIBC;SUNOS;HASUNIX';
-dFPC_USE_LIBC would just affect the "uses SysCall" (and that
hopefully in *exactly* the same manner as compiling on sunos)
- Does it need to be guarded {$IFnDEF LIBC} ?
That define would be FPC_USE_LIBC. But afaik that is only defined ad
hoc on spots where it is needed during the FPC compilation. I.e. it is
set in the build system rather than being a compiler built in. So no.
Sure?
-dFPC_USE_LIBC would be specified be the user or Makefile when the
fpc/rtl is build.
But when an fpc (that had been build with -dFPC_USE_LIBC ) is used to
compile a random project, will then this fpc by tiself define
-dFPC_USE_LIBC (without the user needing to do so?)
--
I have 2 different concerns
1) What happens on sunos?
(Where the compiler defaults to LIBC)
That is the case I wont to cover.
2) What happens, if the user "tampers" with settings building a non
default fpc.
That 2nd part is not that important in respect to my questions in this mail.
If the user does that, then (when compiling lazarus or any project)
- no special define may be set by FPC (and that is ok)
- the user may have to set a define according to the project (lazarus
could offer a workaround define)
-
as for point 1
To make sure it compiles with
- normal build fpc on linux/darwin
- normal build fpc on sunos
{$ifdef linux}
uses SysCall;
{$endif}
{$ifdef darwin}
{$DEFINE FPDEBUG_USE_LIBC} // darwin: always libc
{$else}
{$IF not declared(Do_SysCall)} // Linux, but no Do_SysCall
{$IFDEF LIBC} // Does this define ever exist (by fpc)
{$DEFINE FPDEBUG_USE_LIBC} // no DoSysCall ==> use libc
{$ELSE}
{$DEFINE FPDEBUG_USE_DUMMY} // no DoSysCall ==> empty dummy proc
{$ENDIF}
{$ENDIF}
// ELSE: Do_Syscall exists and can be used
{$endif}
Will that work?
==>> Will (on linux, including sunos)
"uses SysCall"
compile (not throw an error during compilation). (that is for NORMAL /
non-tampered FPC)
If yes, then that should work. (even if LIBC isn't defined)
If yes, then I can check if "DoSysCall" can be used
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] defines by the compiler... / linux, LIBC, SysCall
Is this page up to date?
https://www.freepascal.org/docs-html/prog/progap7.html
Maybe I am wrong, but looking at the tsysteminfo does the value in
extradefines specify values that will be defined during compilation
(such as those given on that page)?
If the do then "sunos" has
extradefines : 'UNIX;LIBC;SUNOS;HASUNIX';
But neither LIBC nor HASUNIX are listed on that page.
---
I don't have sunos for testing.
But https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40575
The primary target is to avoid compilation errors.
All the below guarded by {$ifdef linux}
1) I can add "uses SysCall".
There is a comment this will work in 3.3.1 / not sure if 3.2.x will
abort compile, or just use some unit without the expected symbol.
So the question is (for compilers starting at 3.2.0 // that is one
version back)
- Can (on any linux/unix) "uses SysCall" be compiled (without error)
- Does it need to be guarded {$IFnDEF LIBC} ?
2) If it can always be used, I can then check
{$IF declared(Do_SysCall)}
3) If Do_SysCall is not avail
Does FPC then provide the define LIBC?
So could I do
{$IF declared(Do_SysCall)}
// code uses Do_SysCall
{$ELSE}
{$IFDEF LIBC}
// code imports ptrace from libc
{$ELSE}
// code defines empty dummy "raise Exception.create('not
supported');"
// compiles, but wont work
{$ENDIF}
{$ENDIF}
Thanks for any help/feedback.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] WordBool or SmallInt ?
fpc 3.2.3 The below prog prints 3 times: 11, -1 (signed values) https://www.freepascal.org/docs-html/current/ref/refsu4.html#x26-250003.1.1 Free Pascal also supports the ByteBool, WordBool, LongBool and QWordBool types. These are of type Byte, Word, Longint or Int64, Besides the fact that a "QWordBool" should be "Int64", they all seem to be treated as signed. Yet at least the first two of them are documented as unsigned. program Project1; var b1,b2 : wordbool; b3,b4 : longbool; b5,b6 : qwordbool; begin b1 := wordBool(11); b2 := wordBool(-1); writeln(ord(b1)); writeln(ord(b2)); writeln; b3 := LongBool(11); b4 := LongBool(-1); writeln(ord(b3)); writeln(ord(b4)); writeln; b5 := qwordBool(11); b6 := qwordBool(-1); writeln(ord(b5)); writeln(ord(b6)); readln; end. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Ascending order of enum vals
Enums must be ascending. Otherwise a compiler note will be issued... Or not. Below prog gives project1.lpr(4,32) Note: Values in enumeration types have to be ascending But if the values are cast first, then no warning. The 2nd line will print 255, 0,-2 => which is not ascending. program Project1; type TMyEnum = (e1:=-1,e2:=0, e3:=-2); //TMyEnum = (e1:=byte(-1),e2:=0, e3:=-2); //TMyEnum = (e1:=-1,e2:=0, e3:=qword(-2)); var xa: TMyEnum; begin writeln(ord(e1)); writeln(ord(e2)); writeln(ord(e3)); readln; end. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TProcess and redirection of StdIn/Out (e.g. from/to files)
On 14/12/2023 21:33, Marco van de Voort via fpc-devel wrote: Op 14-12-2023 om 21:27 schreef Martin Frb via fpc-devel: I am actually pretty sure, on Linux, I can get what I want by doing it in the "OnFork" event of TProcess. But on Windows it is well hidden away in the "Execute" method, nothing virtual that could be intercepted. Change the input handle and use popassinput ? As I said, not possible (unless I make a copy of the entire TProcess code). There is no way to intercept "Execute", and it must be done before the Windows API is called to create the process. But I wonder if this is not too specialistic. It depends on how well you can abstract it into TProcess, and preferably in a somewhat similar way for all OSes. Well Michael's answer looks like he is about to have what I need. Depends on the when... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TProcess and redirection of StdIn/Out (e.g. from/to files)
On 14/12/2023 20:54, Marco van de Voort via fpc-devel wrote: Op 14-12-2023 om 20:29 schreef Martin Frb via fpc-devel: Op 14-12-2023 om 17:30 schreef Martin Frb via fpc-devel: If I am right the TProcess currently does not allow redirection of StdOut/In to/from a file (or other handle provided). It does, if you need a runcommandloop like routine that writes to file. Partially this can be even simplified by inheriting TProcess and overriding readinputstream But that means the parent process has to read the data (from the file) and forward it. Without a shell that always needs to happen. How else ? Keep in mind that TProcess is a kernel and not a shell level concept. At least on Windows you can give a handle that is to be used as StdIn. And on Linux that handle is currently setup after the fork event, in the new process => and currently it either is a pipe or (I think) a copy of the parent stdin. But nothing stops it to be a filehandle. But afaik StdIn is just a handle. This handle can be a tty (usually if there is a shell), but it can be /dev/nil or a file or ... I am actually pretty sure, on Linux, I can get what I want by doing it in the "OnFork" event of TProcess. But on Windows it is well hidden away in the "Execute" method, nothing virtual that could be intercepted. Also not sure how to simulate an EOF in that case Probably close the pipe. Anyway the full project is here: http://www.stack.nl/~marcov/files/processmemodemo.zip It is slightly different, a TProcess based application that tries to instrument a secondary binary. Thanks, but I consider that a worst case work around. I'd rather copy the entire TProcess, so I can make a few tiny changes in TProcess.Execute. I already done a proof of concept on win: - get the handle to the file - pass it to the WinAPI for creating the process => works. Haven't yet looked at Linux. But should be even easier. - The reason I ask is, that if there is a chance of a future solution in FPC, then I like to avoid my own solution now until I can at least do my own solution in a compatible manner. For that I would have to know enough details on that future solution. Well depending on the amount of changes, I may still do my own incompatible ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TProcess and redirection of StdIn/Out (e.g. from/to files)
On 14/12/2023 18:13, Marco van de Voort via fpc-devel wrote: Op 14-12-2023 om 17:30 schreef Martin Frb via fpc-devel: If I am right the TProcess currently does not allow redirection of StdOut/In to/from a file (or other handle provided). It does, if you need a runcommandloop like routine that writes to file. Partially this can be even simplified by inheriting TProcess and overriding readinputstream But that means the parent process has to read the data (from the file) and forward it. Also not sure how to simulate an EOF in that case Is this something that should be added? (I.e. a feature request to be added) If yes, should there just be 3 properties for the handles? A callback to create/provide them? A virtual method? Should there be a flag? Maybe you can create a predefined derivative that does this with less additional code, but this should already be possible. Afaik, only if the parent process does the forwarding. If the parent process is busy the child process will need to wait... If the parent process wants to launch the child, and the parent then exits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TProcess and redirection of StdIn/Out (e.g. from/to files)
On 14/12/2023 18:06, Michael Van Canneyt via fpc-devel wrote: Actually, I already started an implementation of an extension half a year ago. Is there an accessible branch for that? (maybe in a fork?) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] TProcess and redirection of StdIn/Out (e.g. from/to files)
If I am right the TProcess currently does not allow redirection of StdOut/In to/from a file (or other handle provided). If it does, and I have been missing the "how to", then please enlighten me and disregard the remainder of the mail. The code for setting up redirection to pipes (to be read/write by the parent process) already exists. So this is mainly a call to add properties to explicitly set those handles. Or provide some other method. Is this something that should be added? (I.e. a feature request to be added) If yes, should there just be 3 properties for the handles? A callback to create/provide them? A virtual method? Should there be a flag? What should be the resolving order if handles are give, but other flags (pipes/input) are set? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] ""make clean" builds ppc1 [[Re: Getting error building fpc for clang 16]]
On 09/12/2023 17:03, Martin Frb via fpc-devel wrote: Anyway, I changed the make make install INSTALL_PREFIX=/home/m/fpc/$INSTPATH/gw3 OPT=" -Clv16.0 " LLVM=1 Then next it fails, with the same error on make clean Yes, it tries to compile a file while doing "make clean" Even stranger, if I do delete the ppc1 before "make clean" rm /home/m/fpc/$INSTSRC/source/compiler/ppc* Then "make clean" will build a new ppc1. Why? make cycleclean make[5]: Entering directory '/home/m/fpc/rel_3.3.1/source/compiler' /usr/bin/rm -f x86_64/bin/x86_64-linux/pp x86_64/bin/x86_64-linux/pp.o x86_64/bin/x86_64-linux/pp.bclibppp.a x86_64/bin/x86_64-linux/libimppp.a /usr/bin/rm -rf units /usr/bin/rm -rf bin /usr/bin/rm -f *.o *.bc *.ppu *.rst *.s *.a *.so *.ppl /usr/bin/rm -rf *.sl /usr/bin/rm -f fpcmade.* Package.fpc *.fpm /usr/bin/rm -f script*.res link*.res *_script.res *_link.res /usr/bin/rm -f ./ppas.sh *_ppas.sh ppas.sh ppaslink.sh make -C utils cleanall make[6]: Entering directory '/home/m/fpc/rel_3.3.1/source/compiler/utils' /usr/bin/rm -f fpc ppufiles ppudump ppumove mka64ins mkarmins mkx86ins msg2inc mkx86inl mkz80ins fpc.o ppufiles.o ppudump.o ppumove.o mka64ins.o mkarmins.o mkx86ins.o msg2inc.o mkx86inl.o mkz80ins.o fpc.bc ppufiles.bc ppudump.bc ppumove.bc mka64ins.bc mkarmins.bc mkx86ins.bc msg2inc.bc mkx86inl.bc mkz80ins.bclibpfpc.a libpppufiles.a libpppudump.a libpppumove.a libpmka64ins.a libpmkarmins.a libpmkx86ins.a libpmsg2inc.a libpmkx86inl.a libpmkz80ins.a libimpfpc.a libimpppufiles.a libimpppudump.a libimpppumove.a libimpmka64ins.a libimpmkarmins.a libimpmkx86ins.a libimpmsg2inc.a libimpmkx86inl.a libimpmkz80ins.a /usr/bin/rm -f units/x86_64-linux/ppu.ppu units/x86_64-linux/crc.ppu /usr/bin/rm -rf units /usr/bin/rm -rf bin /usr/bin/rm -f *.o *.bc *.ppu *.rst *.s *.a *.so *.ppl /usr/bin/rm -rf *.sl /usr/bin/rm -f fpcmade.* Package.fpc *.fpm /usr/bin/rm -f script*.res link*.res *_script.res *_link.res /usr/bin/rm -f ./ppas.sh *_ppas.sh ppas.sh ppaslink.sh make[6]: Leaving directory '/home/m/fpc/rel_3.3.1/source/compiler/utils' /usr/bin/rm -rf x86_64/units /usr/bin/rm -rf x86_64/bin /usr/bin/rm -f x86_64/*.o x86_64/*.ppu x86_64/*.rst x86_64/*.s x86_64/*.a x86_64/*.so x86_64/*.ppl /usr/bin/rm -f x86_64/ppc386 x86_64/ppc68k x86_64/ppcppc x86_64/ppcsparc x86_64/ppcarm x86_64/ppcarmeb x86_64/ppcx64 x86_64/ppcppc64 x86_64/ppcmips x86_64/ppcmipsel x86_64/ppcmips64 x86_64/ppcmips64el x86_64/ppcavr x86_64/ppcjvm x86_64/ppc8086 x86_64/ppca64 x86_64/ppcsparc64 x86_64/ppcrv32 x86_64/ppcrv64 x86_64/ppcxtensa x86_64/ppcz80 x86_64/ppcwasm32 x86_64/ppcloongarch64 /usr/bin/rm -f ppcx64 make[5]: Leaving directory '/home/m/fpc/rel_3.3.1/source/compiler' make compiler make[5]: Entering directory '/home/m/fpc/rel_3.3.1/source/compiler' /usr/bin/mkdir -p x86_64/units/x86_64-linux /usr/bin/mkdir -p x86_64/bin/x86_64-linux /home/m/fpc/svn/ppcx64_3_2_2 -Ur -Xs -O2 -n -Fux86_64 -Fusystems -Fu/home/m/fpc/rel_3.3.1/source/rtl/units/x86_64-linux -Fix86_64 -FEx86_64/bin/x86_64-linux -FUx86_64/units/x86_64-linux -Cg -Fl/usr/lib/gcc/x86_64-redhat-linux/13 -dRELEASE -O-1 -gw3 -dx86_64 -dGDB -dllvm -Fullvm -Fux86 -Fix86 -o/home/m/fpc/rel_3.3.1/source/compiler/ppc1 pp.pas make[5]: Leaving directory '/home/m/fpc/rel_3.3.1/source/compiler' ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Getting error building fpc for clang 16
On 09/12/2023 10:50, Jonas Maebe via fpc-devel wrote:
On 07/12/2023 13:52, Martin Frb via fpc-devel wrote:
I also looked for msg2inc. And msg2inc was compiled before
Maybe check the timestamps of compiler/msg*.inc,
compiler/utils/msg2inc.pp and compiler/msg/errore.msg. Perhaps some of
those have timestamps far in the future?
The seem ok to me. Either checkout date, or build date.
Anyway, I changed the make
make install INSTALL_PREFIX=/home/m/fpc/$INSTPATH/gw3 OPT="
-Clv16.0 " LLVM=1
Then next it fails, with the same error on
make clean
Yes, it tries to compile a file while doing "make clean"
Interestingly, "make clean" refuses to start, unless it has a compiler
in path (ok, even if it should not need it, as it should not compile
anything...), but then it uses source/compiler/ppc1
make[8]: '/home/m/fpc/rel_3.3.1/source/rtl/units/x86_64-linux' is up to
date.
make[8]: Leaving directory '/home/m/fpc/rel_3.3.1/source/rtl/linux'
as --64 -o /home/m/fpc/rel_3.3.1/source/rtl/units/x86_64-linux/abitag.o
x86_64/abitag.as
/home/m/fpc/rel_3.3.1/source/compiler/ppc1 -Ur -Ur -Xs -O2 -n -Fi../inc
-Fi../x86_64 -Fi../unix -Fix86_64 -FE.
-FU/home/m/fpc/rel_3.3.1/source/rtl/units/x86_64-linux -Cg
-Fl/usr/lib/gcc/x86_64-redhat-linux/13 -O-1 -gw3 -dx86_64 -dRELEASE -Us
-Sg system.pp
/home/m/fpc/rel_3.3.1/source/rtl/units/x86_64-linux/system.ll:9990:76:
error: expected '('
define void @"\01SYSTEM_$$_STRPAS$PANSICHAR$$SHORTSTRING"([256 x i8]*
sret noalias nocapture %p.$result, i8* %p.p) inlinehint nobuiltin
"null-pointer-is-valid"="true" strictfp !dbg !1643 {
^
1 error generated.
--
the files with date, after "make all" before "make install" got started:
[m@fedora fpc]$ find rel_3.3.1/source/ -name '*msg2inc*' | xargs ls -la
-rwxr-xr-x. 1 m m 341048 Dec 9 12:12
rel_3.3.1/source/compiler/utils/msg2inc
-rw-r--r--. 1 m m 20180 Dec 6 23:07
rel_3.3.1/source/compiler/utils/msg2inc.pp
-rw-r--r--. 1 m m 63416 Dec 9 12:12
rel_3.3.1/source/compiler/utils/units/x86_64-linux/msg2inc.o
[m@fedora fpc]$ ls -la rel_3.3.1/source/compiler/msg*inc*
-rw-r--r--. 1 m m 47096 Dec 6 23:07 rel_3.3.1/source/compiler/msgidx.inc
-rw-r--r--. 1 m m 112167 Dec 6 23:07 rel_3.3.1/source/compiler/msgtxt.inc
[m@fedora fpc]$ ls -la rel_3.3.1/source/compiler/msg/*
-rw-r--r--. 1 m m 139307 Dec 6 23:07
rel_3.3.1/source/compiler/msg/errorct.msg
-rw-r--r--. 1 m m 244571 Dec 6 23:07
rel_3.3.1/source/compiler/msg/errorda.msg
-rw-r--r--. 1 m m 304534 Dec 6 23:07
rel_3.3.1/source/compiler/msg/errord.msg
-rw-r--r--. 1 m m 305647 Dec 6 23:07
rel_3.3.1/source/compiler/msg/errordu.msg
-rw-r--r--. 1 m m 291024 Dec 6 23:07
rel_3.3.1/source/compiler/msg/errore.msg
-rw-r--r--. 1 m m 246429 Dec 6 23:07
rel_3.3.1/source/compiler/msg/errores.msg
-rw-r--r--. 1 m m 250649 Dec 6 23:07
rel_3.3.1/source/compiler/msg/errorfi.msg
-rw-r--r--. 1 m m 105908 Dec 6 23:07
rel_3.3.1/source/compiler/msg/errorf.msg
-rw-r--r--. 1 m m 151642 Dec 6 23:07
rel_3.3.1/source/compiler/msg/errorhe.msg
-rw-r--r--. 1 m m 258978 Dec 6 23:07
rel_3.3.1/source/compiler/msg/errorheu.msg
-rw-r--r--. 1 m m 248955 Dec 6 23:07
rel_3.3.1/source/compiler/msg/errorid.msg
-rw-r--r--. 1 m m 188895 Dec 6 23:07
rel_3.3.1/source/compiler/msg/erroriu.msg
-rw-r--r--. 1 m m 241199 Dec 6 23:07
rel_3.3.1/source/compiler/msg/errorn.msg
-rw-r--r--. 1 m m 136463 Dec 6 23:07
rel_3.3.1/source/compiler/msg/errorpli.msg
-rw-r--r--. 1 m m 136451 Dec 6 23:07
rel_3.3.1/source/compiler/msg/errorpl.msg
-rw-r--r--. 1 m m 220070 Dec 6 23:07
rel_3.3.1/source/compiler/msg/errorpt.msg
-rw-r--r--. 1 m m 255864 Dec 6 23:07
rel_3.3.1/source/compiler/msg/errorptu.msg
-rw-r--r--. 1 m m 177521 Dec 6 23:07
rel_3.3.1/source/compiler/msg/errorr.msg
-rw-r--r--. 1 m m 347094 Dec 6 23:07
rel_3.3.1/source/compiler/msg/errorru.msg
-rw-r--r--. 1 m m 246714 Dec 6 23:07
rel_3.3.1/source/compiler/msg/errorues.msg
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Getting error building fpc for clang 16
On 07/12/2023 13:52, Martin Frb via fpc-devel wrote: On 07/12/2023 12:19, Jonas Maebe via fpc-devel wrote: On 2023-12-07 01:09, Martin Frb via fpc-devel wrote: But I am getting make[8]: '/home/m/fpc/rel_3.3.1/source/rtl/units/x86_64-linux' is up to date. make[8]: Leaving directory '/home/m/fpc/rel_3.3.1/source/rtl/linux' as --64 -o /home/m/fpc/rel_3.3.1/source/rtl/units/x86_64-linux/abitag.o x86_64/abitag.as /home/m/fpc/rel_3.3.1/source/compiler/ppc1 -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE. -FU/home/m/fpc/rel_3.3.1/source/rtl/units/x86_64-linux -Cg -Fl/usr/lib/gcc/x86_64-redhat-linux/13 -dx86_64 -dRELEASE -Us -Sg system.pp The -Clv parameter is missing here for some reason, so the compiler is generating code for LLVM 7.0 rather than 16.0. It seems to happen during "make install". Strange, why does it compile during installation? Starting compiler is 3.2.2 I should mention that the compiler is not installed to /usr/ , nor anywhere in a global available place. (As I have several versions on that machine, I made sure non of them has anything in a place where it could be found by others. (that includes no /etc/fpc.cfg, nor fpc.cfg in my home dir. / each fpc has an fpc.cfg inside its install dir) But before the make is called the PATH is set to include the 3.2.2 fpc. I use identical setup on several Linux boxes, including the one that successfully build with clang 11 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Getting error building fpc for clang 16
On 07/12/2023 12:19, Jonas Maebe via fpc-devel wrote:
On 2023-12-07 01:09, Martin Frb via fpc-devel wrote:
But I am getting
make[8]: '/home/m/fpc/rel_3.3.1/source/rtl/units/x86_64-linux' is up
to date.
make[8]: Leaving directory '/home/m/fpc/rel_3.3.1/source/rtl/linux'
as --64 -o
/home/m/fpc/rel_3.3.1/source/rtl/units/x86_64-linux/abitag.o
x86_64/abitag.as
/home/m/fpc/rel_3.3.1/source/compiler/ppc1 -Ur -Ur -Xs -O2 -n
-Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE.
-FU/home/m/fpc/rel_3.3.1/source/rtl/units/x86_64-linux -Cg
-Fl/usr/lib/gcc/x86_64-redhat-linux/13 -dx86_64 -dRELEASE -Us -Sg
system.pp
The -Clv parameter is missing here for some reason, so the compiler is
generating code for LLVM 7.0 rather than 16.0.
It seems to happen during "make install". Strange, why does it compile
during installation?
My script issues the following commands:
(I am using the same on another machine with clang 11)
make clean
make all OPT=" " OPTNEW=" -Clv16.0 " FPCMAKEOPT=" -Clv16.0 " LLVM=1
make install INSTALL_PREFIX=/home/m/fpc/$INSTPATH/def LLVM=1
The captured output does not have the commands itself, only the output
The "100%" should still be from the "make all" (there is no install in
the text before that)
I assume "installbase" is the start of the output of above make install.
And then it starts the compiler Why?
Before that there are 10 other occurrences of
"Entering directory '/home/m/fpc/rel_3.3.1/source/compiler/utils'"
[100%] Compiled package utils-wasmbin
make[2]: Leaving directory '/home/m/fpc/rel_3.3.1/source/utils'
make[1]: Leaving directory '/home/m/fpc/rel_3.3.1/source'
/usr/bin/echo Build > build-stamp.x86_64-linux
/usr/bin/echo Build > base.build-stamp.x86_64-linux
make installbase FPC=/home/m/fpc/rel_3.3.1/source/compiler/ppcx64
ZIPDESTDIR=/home/m/fpc/rel_3.3.1/source
FPCMAKE=/home/m/fpc/rel_3.3.1/source/utils/fpcm/bin/x86_64-linux/fpcmake
make[1]: Entering directory '/home/m/fpc/rel_3.3.1/source'
/usr/bin/install -m 755 -d /home/m/fpc/rel_3.3.1/clang64/def/lib/fpc/3.3.1
/usr/bin/install -m 755 -d /home/m/fpc/rel_3.3.1/clang64/def/bin
make compiler_distinstall
FPC=/home/m/fpc/rel_3.3.1/source/compiler/ppcx64
ZIPDESTDIR=/home/m/fpc/rel_3.3.1/source
FPCMAKE=/home/m/fpc/rel_3.3.1/source/utils/fpcm/bin/x86_64-linux/fpcmake
make[2]: Entering directory '/home/m/fpc/rel_3.3.1/source'
make -C compiler distinstall
make[3]: Entering directory '/home/m/fpc/rel_3.3.1/source/compiler'
make quickinstall auxfilesinstall
make[4]: Entering directory '/home/m/fpc/rel_3.3.1/source/compiler'
make -C utils install
make[5]: Entering directory '/home/m/fpc/rel_3.3.1/source/compiler/utils'
/home/m/fpc/rel_3.3.1/source/compiler/ppcx64 -Ur -Xs -O2 -n -Fu..
-Fu/home/m/fpc/rel_3.3.1/source/rtl/units/x86_64-linux -FE.
-FUunits/x86_64-linux -Cg -Fl/usr/lib/gcc/x86_64-redhat-linux/13
-dx86_64 -dRELEASE msg2inc.pp
units/x86_64-linux/msg2inc.ll:663:71: error: expected '('
invoke void (i8**, i8*, i64, i64) @"\01fpc_ansistr_copy" (i8**
sret %reg.1_276, i8* %reg.1_275, i64 %reg.1_274, i64 %reg.1_270) to
label %.Lj88 unwind label %.Lj9
^
1 error generated.
Error: Error while assembling exitcode 1
=
I also looked for msg2inc. And msg2inc was compiled before
msg2inc.pp is only twice in the log. As below, and as in the error above
Without the pp extension it is present in a few "rm". All above the
below snippet
make[5]: Leaving directory '/home/m/fpc/rel_3.3.1/source/compiler/utils'
/home/m/fpc/rel_3.3.1/source/compiler/ppcx64 -Clv16.0 -Ur -Xs -O2 -n
-Fu.. -Fu/home/m/fpc/rel_3.3.1/source/rtl/units/x86_64-linux -FE.
-FUunits/x86_64-linux -Cg -Fl/usr/lib/gcc/x86_64-redhat-linux/13
-dx86_64 -dRELEASE mka64ins.pp
/home/m/fpc/rel_3.3.1/source/compiler/ppcx64 -Clv16.0 -Ur -Xs -O2 -n
-Fu.. -Fu/home/m/fpc/rel_3.3.1/source/rtl/units/x86_64-linux -FE.
-FUunits/x86_64-linux -Cg -Fl/usr/lib/gcc/x86_64-redhat-linux/13
-dx86_64 -dRELEASE mkarmins.pp
/home/m/fpc/rel_3.3.1/source/compiler/ppcx64 -Clv16.0 -Ur -Xs -O2 -n
-Fu.. -Fu/home/m/fpc/rel_3.3.1/source/rtl/units/x86_64-linux -FE.
-FUunits/x86_64-linux -Cg -Fl/usr/lib/gcc/x86_64-redhat-linux/13
-dx86_64 -dRELEASE mkx86ins.pp
/home/m/fpc/rel_3.3.1/source/compiler/ppcx64 -Clv16.0 -Ur -Xs -O2 -n
-Fu.. -Fu/home/m/fpc/rel_3.3.1/source/rtl/units/x86_64-linux -FE.
-FUunits/x86_64-linux -Cg -Fl/usr/lib/gcc/x86_64-redhat-linux/13
-dx86_64 -dRELEASE msg2inc.pp
/home/m/fpc/rel_3.3.1/source/compiler/ppcx64 -Clv16.0 -Ur -Xs -O2 -n
-Fu.. -Fu/home/m/fpc/rel_3.3.1/source/rtl/units/x86_64-linux -FE.
-FUunits/x86_64-linux -Cg -Fl/usr/lib/gcc/x86_64-redhat-linux/13
-dx86_64 -dRELEASE mkx86inl.pp
/home/m/fpc/rel_3.3.1/source/compiler/ppcx64 -Clv16.0 -Ur -Xs -O2 -n
-Fu.. -Fu/home/m/fpc/rel_3.3
[fpc-devel] Getting error building fpc for clang 16
I was trying to build an fpc for clang 16 (same commands worked on a
diff machine for clang 11)
I changed the version in the make line:
make all OPT=" " OPTNEW=" -Clv16.0 " FPCMAKEOPT=" -Clv16.0 " LLVM=1
I also tried version 16.0.6
fpc 49cb7b256476409924c581145a760b863b9e755d
(I had tried earlier with an older fpc on that machine. I don't know if
the error was the same)
clang --version
clang version 16.0.6 (Fedora 16.0.6-3.fc38)
Target: x86_64-redhat-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
But I am getting
make[8]: '/home/m/fpc/rel_3.3.1/source/rtl/units/x86_64-linux' is up to
date.
make[8]: Leaving directory '/home/m/fpc/rel_3.3.1/source/rtl/linux'
as --64 -o /home/m/fpc/rel_3.3.1/source/rtl/units/x86_64-linux/abitag.o
x86_64/abitag.as
/home/m/fpc/rel_3.3.1/source/compiler/ppc1 -Ur -Ur -Xs -O2 -n -Fi../inc
-Fi../x86_64 -Fi../unix -Fix86_64 -FE.
-FU/home/m/fpc/rel_3.3.1/source/rtl/units/x86_64-linux -Cg
-Fl/usr/lib/gcc/x86_64-redhat-linux/13 -dx86_64 -dRELEASE -Us -Sg system.pp
/home/m/fpc/rel_3.3.1/source/rtl/units/x86_64-linux/system.ll:9713:76:
error: expected '('
define void @"\01SYSTEM_$$_STRPAS$PANSICHAR$$SHORTSTRING"([256 x i8]*
sret noalias nocapture %p.$result, i8* %p.p) inlinehint nobuiltin
"null-pointer-is-valid"="true" strictfp {
^
1 error generated.
system.pp(747,1) Error: Error while assembling exitcode 1
system.pp(747,1) Fatal: There were 2 errors compiling module, stopping
Fatal: Compilation aborted
make[7]: *** [Makefile:2870: system.ppu] Error 1
make[7]: Leaving directory '/home/m/fpc/rel_3.3.1/source/rtl/linux'
make[6]: *** [Makefile:2367: linux_all] Error 2
make[6]: Leaving directory '/home/m/fpc/rel_3.3.1/source/rtl'
make[5]: *** [Makefile:5486: rtl] Error 2
make[5]: Leaving directory '/home/m/fpc/rel_3.3.1/source/compiler'
make[4]: *** [Makefile:5319: next] Error 2
make[4]: Leaving directory '/home/m/fpc/rel_3.3.1/source/compiler'
make[3]: *** [Makefile:5327: ppc2] Error 2
make[3]: Leaving directory '/home/m/fpc/rel_3.3.1/source/compiler'
make[2]: *** [Makefile:5337: cycle] Error 2
make[2]: Leaving directory '/home/m/fpc/rel_3.3.1/source/compiler'
make[1]: *** [Makefile:3256: compiler_cycle] Error 2
make[1]: Leaving directory '/home/m/fpc/rel_3.3.1/source'
make: *** [Makefile:3288: build-stamp.x86_64-linux] Error 2
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Wrong debug info when using clang backend
On 06/12/2023 21:58, Martin Frb via fpc-devel wrote: On 06/12/2023 21:05, Jonas Maebe via fpc-devel wrote: On 06/12/2023 17:37, Martin Frb via fpc-devel wrote: Not suer if the issue is within Fpc or clang... Should this be reported against Fpc? FPC defines the variables' debug info at the start of the function and defines their lifetime as starting at the beginning of the function and continuing until the end. But LLVM is free to modify these if it notices these are too pessimistic My guess is that even without optimisations, LLVM notices these variables' values are not really used later on and reduces the variables' live range. Strange, then clang has a serious issue. But, yes it probably is clang. If I have enough code, so clang does not optimize the entire function away in -O1, then clang writes info for some of the lines. Actually the variable is in a (or several?) registers. And clang misses some lines too. But it covers some lines in the procedure. With -O- it never is in a register... Well it gets loaded sometimes, but it' always also on the stack. Seems like clang doesn't see it while it is on the stack. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Wrong debug info when using clang backend
On 06/12/2023 21:05, Jonas Maebe via fpc-devel wrote:
On 06/12/2023 17:37, Martin Frb via fpc-devel wrote:
Not suer if the issue is within Fpc or clang...
Should this be reported against Fpc?
FPC defines the variables' debug info at the start of the function and
defines their lifetime as starting at the beginning of the function
and continuing until the end. But LLVM is free to modify these if it
notices these are too pessimistic
My guess is that even without optimisations, LLVM notices these
variables' values are not really used later on and reduces the
variables' live range.
Strange, then clang has a serious issue.
I changed the code, so they are used. Still clang only defines the
location list for the "end" keyword.
(I also removed the nested aspect)
Which in this case is
/home/m/laz/projects/clang1/clang_nested_proc_1.lpr:17 end;
0040143A 4883C448 add rsp,$48
0040143E C3 ret
And the location list covers those 2 statements.
Maybe it's the version of clang (if anyone has a newer one setup...)
Is there a way to see what fpc tells clang? (in human readable form)
program clang_nested_proc_1;
{$mode objfpc}
procedure Bar(a, b: integer);
var
c,d: integer;
begin
c:=Random(99);
d:=Random(99);
writeln(a,b,c,d);
d:=d+a;
c:=c+b;
writeln(a,b,c,d);
end;
procedure Foo;
begin
Bar(1,2);
end;
begin
Foo;
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Wrong debug info when using clang backend
Not suer if the issue is within Fpc or clang...
Should this be reported against Fpc?
- Fedora 33
- Fpc 3.3.1 from Sept 26th
- make all OPT=" " OPTNEW=" -Clv11.0 " FPCMAKEOPT=" -Clv11.0 " LLVM=1
- clang --version
clang version 11.0.0 (Fedora 11.0.0-3.fc33)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Program at the end of this mail was compiled with -O-
Assembler for nested procedure Bar
/home/m/laz/projects/clang1/clang_nested_proc_1.lpr:8 begin
004012D0 897424F8 mov [rsp-$08],esi
004012D4 895424F0 mov [rsp-$10],edx
/home/m/laz/projects/clang1/clang_nested_proc_1.lpr:9 a := 1;
004012D8 C74424F80100 mov [rsp-$08],$0001
/home/m/laz/projects/clang1/clang_nested_proc_1.lpr:10 b := 1;
004012E0 C74424F00100 mov [rsp-$10],$0001
/home/m/laz/projects/clang1/clang_nested_proc_1.lpr:11 c:=2;
004012E8 C74424E40200 mov [rsp-$1C],$0002
/home/m/laz/projects/clang1/clang_nested_proc_1.lpr:12 d:=2;
004012F0 C74424E00200 mov [rsp-$20],$0002
/home/m/laz/projects/clang1/clang_nested_proc_1.lpr:13 d:=2;
004012F8 C74424E00200 mov [rsp-$20],$0002
/home/m/laz/projects/clang1/clang_nested_proc_1.lpr:14 end;
00401300 C3 ret
Variables d and c are encoded using a location list
<2><9c>: Abbrev Number: 3 (DW_TAG_variable)
<9d> DW_AT_location : 0x24 (location list)
DW_AT_name : (indirect string, offset: 0xab): D
DW_AT_decl_file : 1
DW_AT_decl_line : 7
DW_AT_type : <0xdb>
<2>: Abbrev Number: 3 (DW_TAG_variable)
DW_AT_location : 0x48 (location list)
DW_AT_name : (indirect string, offset: 0xad): C
DW_AT_decl_file : 1
DW_AT_decl_line : 7
DW_AT_type : <0xdb>
Contents of the .debug_loc section:
Offset Begin End Expression
004012c3 004012c5 (DW_OP_breg7 (rsp): 0)
0014
0024 00401300 00401301 (DW_OP_breg7 (rsp): -32)
0038
0048 00401300 00401301 (DW_OP_breg7 (rsp): -28)
005c
Both location lists specify the variable is only available from
00401300 00401301
- That covers exactly the asm "ret" statement.
- Yet the variables are stored on the frame ([rsp-$1C] / [rsp-$20]) =>
so they are available before.
program clang_nested_proc_1;
{$mode objfpc}
procedure Foo;
procedure Bar(a, b: integer);
var
c,d: integer;
begin
a := 1;
b := 1;
c:=2;
d:=2;
d:=2;
end;
begin
Bar(1,2);
end;
begin
Foo;
end.
line info confirms the addresses from the asm.
Contents of the .debug_line section:
CU: clang_nested_proc_1.lpr:
File name Line number Starting address
View Stmt
clang_nested_proc_1.lpr 15 0x4012b0 x
clang_nested_proc_1.lpr 16 0x4012b4 x
clang_nested_proc_1.lpr 17 0x4012c3 x
clang_nested_proc_1.lpr 8 0x4012d0 x
clang_nested_proc_1.lpr 8 0x4012d0 1 x
clang_nested_proc_1.lpr 9 0x4012d8 x
clang_nested_proc_1.lpr 10 0x4012e0 x
clang_nested_proc_1.lpr 11 0x4012e8 x
clang_nested_proc_1.lpr 12 0x4012f0 x
clang_nested_proc_1.lpr 13 0x4012f8 x
clang_nested_proc_1.lpr 14 0x401300 x
clang_nested_proc_1.lpr 19 0x401310 x
clang_nested_proc_1.lpr 19 0x401311 x
clang_nested_proc_1.lpr 20 0x401316 x
clang_nested_proc_1.lpr 21 0x40131b x
clang_nested_proc_1.lpr 21 0x401322 x
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] vargars vs array of const for WinAPI
On 09/11/2023 22:19, Marco van de Voort via fpc-devel wrote: Op 9-11-2023 om 20:47 schreef Martin Frb via fpc-devel: I saw that in some places (I think gtk2) "varargs" is used for open arrray API calls. Any reason that is not adapted for Windows (overloaded)? It probably is newer (kylix). I'm not sure anyway what the problem is? Why would varargs be better Not a big deal... Just in case of porting stuff from (newer?) Delphi. Probably only of interrest if both syntax can live as overloads. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug #38492
On 10/11/2023 10:49, Adriaan van Os via fpc-devel wrote: Sorry, but I am looking for a diff for fpc bug #38492. Mantis says "'Fixed in Revision: 38492" which looks like a mistake, as 38492 is the bug number. Also gitlab reports fix #11ef1d17 which is instead a register allocation fix. Is the fix already in fpc-3.2 fixes ? searching the log messages: ff3f812d979e57b49463224a814c64e027670d2d * * fix conversion of true/false macro definitions to boolean values (mantis #38492) o since the macro lookups are recursive, "mac" will usually be nil afterwards (unless we found an undefined macro) git-svn-id: trunk@49160 - And (if this is the correct commit) you can check if this file is in fixes (newly added) \tests\webtbs\tw38492.pp ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] vargars vs array of const for WinAPI
I saw that in some places (I think gtk2) "varargs" is used for open arrray API calls. Any reason that is not adapted for Windows (overloaded)? function wsprintfA(_para1:LPSTR; _para2:LPCSTR; const args:array of const):longint; cdecl; external 'user32' name 'wsprintfA'; function wsprintf(_para1:LPSTR; _para2:LPCSTR; const args:array of const):longint; cdecl; external 'user32' name 'wsprintfA'; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] About the var param in CreateConsoleScreenBuffer
On 09/11/2023 14:19, Marco van de Voort via fpc-devel wrote: Anyway, standard procedure in such cases is to move the pascallized declaration to redef.inc and have a pointer value in the original place. Which I just commited to GIT. Thanks. Merge-able? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] About the var param in CreateConsoleScreenBuffer
Fpc defines function CreateConsoleScreenBuffer(dwDesiredAccess:DWORD; dwShareMode:DWORD; var lpSecurityAttributes:SECURITY_ATTRIBUTES; dwFlags:DWORD; lpScreenBufferData:LPVOID):HANDLE; external 'kernel32' name 'CreateConsoleScreenBuffer'; `lpSecurityAttributes` is a `var` param in the above. But https://learn.microsoft.com/en-us/windows/console/createconsolescreenbuffer states that the param is optional and can be null/nil. var param don't accept nil. So this should be a pointer instead. Yet, this was reported in https://gitlab.com/freepascal.org/fpc/source/-/issues/5836 That issue got closed "*Fixed in version:* 1.9.9" Only "git blame" shows no change to that line ever. (Well afaik some commits are not in git, so could be). So the question is: Was it fixed and broken again? Was it fixed but not committed? Or does the cryptic comment Pascal CONST can be both by reference (thus consuming a *) or by value. This is the only safe way. mean its a "wont fix" ? And if that is the case, then what does this comment mean?___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] make OPT= OPTFPC= NEWOPT=
On 06/10/2023 15:11, Marco van de Voort via fpc-devel wrote: Op 6-10-2023 om 14:28 schreef Martin Frb via fpc-devel: What is the difference between those 3? OPT= always to my best knowledge NEWOPT is opt only for later cycles and the rest, iow not for the first FPC bootstrap cycle (that might be started with an older compiler version). So it is for additional options that are not supported by the bootstrap compiler, but are supported by the newer compiler. Thanks. I may have found why it didn't work. Two OPT for one make. pebkac. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] make OPT= OPTFPC= NEWOPT=
What is the difference between those 3? I came across OPTNEW here https://wiki.freepascal.org/LLVM But now I am trying to play with the rather old fpc build script for the laz installer. And it calls %MAKEEXE% compiler_cycle PP=%RELEASE_PPC% >> %LOGFILE% 2>&1 %MAKEEXE% rtl_clean PP=%COMPILER% >> %LOGFILE% %MAKEEXE% rtl packages PP=%COMPILER% OPT="-Ur -CX" >> %LOGFILE% %MAKEEXE% utils PP=%COMPILER% OPT="-CX -XX -Xs" DATA2INC=%SOURCE_DIR%\utils\data2inc >> ... And giving it just OPT= does not seem to do the trick. Oh, yes of course, ideally rewrite that old script... Well "someday" ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] ppc3.exe ppc386.exe differ: char 665, line 2
I am getting the error in the subject ececf26d872c9fdc0a315c6289df864f66a1f69a make.exe all LINKSMART=1 CREATESMART=1 OPTIMIZE=1 OPT="-CX -gl -O4 -Ooregvar" FPC=C:\FPC\fpc_3.2.2\32\def\bin\i386-win32\fpc.exe OPTNEW="-CX -gl -O4 -Ooregvar" FPMAKEOPT="-T 6" c:/FPC/fpc_3.3.1/source/compiler/ppc3.exe -XX -CX -Ur -Xs -O2 -n -O2 -Fui386 -Fusystems -Fuc:/FPC/fpc_3.3.1/source/rtl/units/i386-win32 -Fii386 -FEi386/bin/i386-win32 -FUi386/units/i386-win32 -dRELEASE -CX -gl -O4 -Ooregvar -CX -gl -O4 -Ooregvar -di386 -dGDB -Fux86 -Fix86 -Sew -oc:/FPC/fpc_3.3.1/source/compiler/ppc386.exe pp.pas make.exe[4]: Leaving directory `c:/FPC/fpc_3.3.1/source/compiler' make.exe echotime make.exe[4]: Entering directory `c:/FPC/fpc_3.3.1/source/compiler' Start now 12:06:00 make.exe[4]: Leaving directory `c:/FPC/fpc_3.3.1/source/compiler' make.exe[3]: Leaving directory `c:/FPC/fpc_3.3.1/source/compiler' B:/FPC/SVN/fpc_build/install/binw32/cmp.exe -i218 ppc3.exe ppc386.exe ppc3.exe ppc386.exe differ: char 665, line 2 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] DW_AT_declaration
While looking at https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/448#note_1540865966 DW_AT_declaration came up. From the DWARF 5 spec A debugging information entry that represents a non-defining or otherwise 11 incomplete declaration of a program entity has a DW_AT_declaration attribute, 12 which is a flag. From further reading through the spec it seems to refer to "the name being declared but not defined" - the actual definition of the type is not included here (may be in a diff scope/unit) - the implementation of the procedure is not included Then I found it in debug info generated by FPC: TScreen = class(TLCLComponent) private const crScreen = Low(TCursor); // use with Screen.BeginTempCursor/EndTempCursor to add Screen.Cursor into the temp list <0>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_name : forms.pp DW_AT_producer : Free Pascal 3.2.3 2023/06/21 DW_AT_comp_dir : B:/lazarus_main/lcl/ ... ... <1><103e29>: Abbrev Number: 20 (DW_TAG_class_type) <103e2a> DW_AT_name : TScreen <103e32> DW_AT_byte_size : 376 ... <2><103e3d>: Abbrev Number: 68 (DW_TAG_member) <103e3e> DW_AT_name : crScreen <103e47> DW_AT_declaration : 1 <103e48> DW_AT_external : 1 <103e49> DW_AT_type : <0x115cf7> <103e4d> DW_AT_const_value : -32768 But this isn't an "incomplete declaration". Everything is in place? Why is the tag added? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Just to confirm, "with" behaviour expected
On 14/08/2023 14:52, Michael Van Canneyt via fpc-devel wrote: On Mon, 14 Aug 2023, Martin Frb via fpc-devel wrote: Does "with" take the "address" of the value, and operate on that address, even if the address of that value could change within the "with" statement. You may not do this. It is even documented. See the remark at the end of this page: https://www.freepascal.org/docs-html/current/ref/refsu62.html#x172-19600013.2.8 Ups, sorry I didn't research the details first. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Just to confirm, "with" behaviour expected
In the below code, the array is resized (and more important relocated in
mem) inside the function "bar".
The commented line (without "with") works as expected.
The "with" line has a different behaviour. I guess it is by design. Just
wanted to confirm.
The version with "with" prints 12345 for " writeln(a[i,j].x);"
For all I can tell the return value of "bar" was written to the old
address of that array-entry.
Does "with" take the "address" of the value, and operate on that
address, even if the address of that value could change within the
"with" statement.
- test was performed with
fpc 3.2.3 -O1
fpc 3.3.1 -O4
program Project1;
{$mode objfpc}
procedure outer;
var
a: array of array of record x:Integer; end;
i, j: integer;
function bar(x: integer): integer;
begin
Result := random(99) + 2 * x;
writeln(Result);
SetLength(a, 3000, 200);
end;
procedure foo;
begin
i := random(99);
j := random(99);
with a[i,j] do x:= bar(x);
//a[i,j].x := bar(a[i,j].x);
end;
begin
SetLength(a, 100, 100);
for i := 0 to 99 do
for j := 0 to 99 do
a[i,j].x := 12345;
foo;
writeln(a[i,j].x);
readln;
end;
begin
outer;
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Maybe room for better documentation? open array as var param
On 20/07/2023 19:24, Michael Van Canneyt via fpc-devel wrote: It's IMO probably better to outright forbid passing open array by reference. printing length(a) after x:=Nil; gives 10, which is simply wrong. The open array is not the same as the dyn array. It is at any point just a slice of the dyn array. (even if the slice has all elements of the dyn array). At no point is it possible to do a SetLength on the open array (and therefore the lenght of the dyn array can't be changed either - not via the open array). In otherwise the reference is only a reference to the members. There is at no point a reference to the dyn array itself, nor to the length. Of course if the underlaying data goes away, then the "var param" open array (same as "const param") points to some memory I don't know if it needs to be forbidden (don't mind if). But I think - explicit documentation - a compiler note or warning might be helpful ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Maybe room for better documentation? open array as var param
For const param, it is well documented that the value (that includes the
variable that is passed) must not be changed.
But for "var param"?
Well maybe, but not explicit
https://www.freepascal.org/docs-html/ref/refsu68.html#x184-20800014.4.5
>> Open parameters can be passed by value, by reference or as a
constant parameter. In the latter cases the procedure receives a pointer
to the actual array.
So a user with sufficient experience could detect that if a pointer is
received, then the value which is pointed to must not be changed.
Maybe that should be mentioned more explicitly.
And maybe it should additionally also be mentioned on
https://www.freepascal.org/docs-html/ref/refsu65.html
Because the below may be unexpected to quite a few users.
It will (at least on my test on windows / of course depends on mem
manager) print numbers starting at 300.
Even so 200++ has been assigned.
But (with sufficient luck or lack of luck) "y" will re-use the memory of
"x". And "a" will then change "y" which may not be expected.
program Project1;
{$mode objfpc}
var x,y: array of integer;
i: Integer;
procedure foo(var a: array of integer);
var
j: Integer;
begin
x := nil;
SetLength(y, 10);
for j := 0 to 9 do y[j] := 200+j;
for j := 0 to 9 do a[j] := 300+j;
end;
begin
SetLength(x, 10);
for i := 0 to 9 do x[i] := 100+i;
foo(x);
for i := 0 to 9 do writeln(y[i]);
readln;
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] cthreads and fpc.cfg?
On 19/07/2023 10:22, Michael Van Canneyt via fpc-devel wrote:
The error is logical. What is not logical is that it pops up now.
By all logic, we should have seen this error pop up as early as 2016.
Why it pops up only now is a mystery that we need to solve...
I don't have all the details, but maybe there is something buried in the
following findings.
The early call to threads happens in
#0 InitCriticalSection (cs=...) at ../inc/thread.inc:229
#1 0x0049ae18 in $create () at
../objpas/sysutils/sysencoding.inc:214
#2 0x004a6749 in $SYSUTILS_$$_init$ () at ../unix/sysutils.pp:1903
#3 0x0041fc27 in $fpc_initializeunits () at ../inc/system.inc:1134
#4 0x004039be in $main () at fpcmkcfg/fpcmkcfg.pp:585
sysencoding.inc:214
class constructor TEncoding.Create;
hasn't changed recently... (according to git blame)
class constructor TEncoding.Create;
var
E: TStandardEncoding;
begin
for E := Low(FStandardEncodings) to High(FStandardEncodings) do
FStandardEncodings[E] := nil;
{$ifdef FPC_HAS_FEATURE_THREADING}
InitCriticalSection(FLock);
{$endif}
end;
I don't know if FPC_HAS_FEATURE_THREADING has changed?
Also
unix/sysutils.pp 1903
hasn't changed recently...
Initialization
InitExceptions; { Initialize exceptions. OS independent }
InitInternational; { Initialize internationalization settings }
SysConfigDir:='/etc'; { Initialize system config dir }
OnBeep:=@SysBeep;
{$ifdef android}
InitAndroid;
{$endif android}
But the function uses a string
SysConfigDir:='/etc';
Disassembly show it call "create" before InitExceptions
This code must have been inserted by the compiler...
So some recent change in string handling, now inserts calls to encoding
create ?
0x4a6740 <$SYSUTILS_$$_init$>: push %rbp
0x4a6741 <$SYSUTILS_$$_init$+1>: mov %rsp,%rbp
0x4a6744 <$SYSUTILS_$$_init$+4>: call 0x49ade0 <$create>
0x4a6749 <$SYSUTILS_$$_init$+9>: call 0x4a14a0
0x4a674e <$SYSUTILS_$$_init$+14>: call 0x4a56a0
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] cthreads and fpc.cfg?
On 18/07/2023 22:56, Martin via fpc-devel wrote: Using 33dba315366ec3002e062c3aa6dcb15b88356580 (3.3.1) My fpc.cfg looks like this / any idea?: Threading has been used before cthreads was initialized. Make cthreads one of the first units in your uses clause. tried 757f65d0e283c9fd33f2f99e794203590711c686 still... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Before 3.4 gets on the road, can anyone help with fpc Dwarf-properties extension (started by Joost)
Currently the debugger can not show properties (even though it can call
functions).
DWARF does not know properties, but custom tags can be added. Joost
started this in the branch fork-gl/joost/dwarfproperties
https://gitlab.com/freepascal.org/fpc/source/-/tree/joost/dwarfproperties
Rebased at
https://gitlab.com/martin_frb/fpc-src/-/commits/joost-dwarfproperties
I started on reading that info:
https://gitlab.com/martin_frb/lazarus/-/commits/fpdebug-godwarfproperties
See bottom of the mail for Joost's original explanation.
Unfortunately I can't reach Joost.
And I really want that to be in 3.4 (whenever that will be).
Yet there are some issues (I am still testing, just what I found so far)
*** Issue 1)
Sometimes nhe references to the function/member are wrong.
I reproduced with a small test (attached) -gw3 -godwarfproperties
In unit 1, all location for the getters are correct.
getter PropGetter at: 0x13c5
getter PropGetter2 at: 0x142f (0x6a bytes higher)
In dwarf_prop_test.lpr the first property has the correct location for
the getter.
But then the next property does not.
getter PropGetter at: 0x04b8
getter PropGetter2 at: 0x0522 (wrong, but also 0x6a bytes higher)
The actual GetPropGetter2 is at 4dd (only 0x25 bytes higher)
So somehow a value from the other unit was used? Or maybe this is
because the address (low_pc) was omitted in the getter before, but the
size for it was still added to the offset for the next getter?
In unit1
<1><134e>: Abbrev Number: 4 (DW_TAG_class_type)
<2><1381>: Abbrev Number: 7 (Unknown TAG value: 4230)
<1382> DW_AT_name : PropGetter
<138d> Unknown AT value: 3230: <0x13c5>
<2><1391>: Abbrev Number: 7 (Unknown TAG value: 4230)
<1392> DW_AT_name : PropGetter2
<139e> Unknown AT value: 3230: <0x142f>
in dwarf_prop_test.lpr
<1><441>: Abbrev Number: 5 (DW_TAG_class_type)
...
<2><474>: Abbrev Number: 8 (Unknown TAG value: 4230)
<475> DW_AT_name : PropGetter
<480> Unknown AT value: 3230: <0x4b8>
<2><484>: Abbrev Number: 8 (Unknown TAG value: 4230)
<485> DW_AT_name : PropGetter2
<491> Unknown AT value: 3230: <0x522>
...
<2><4b8>: Abbrev Number: 14 (DW_TAG_subprogram)
<4b9> DW_AT_name : GetPropGetter
...
<2><4dd>: Abbrev Number: 14 (DW_TAG_subprogram)
<4de> DW_AT_name : GetPropGetter2
*** Issue 2:
Nothing to do with Joosts code, but on Windows the entry pc for the
methods aren't in the DWARF.
Well, the class is copied into each unit (on Linux there is a cross
compile-units reference).
The copies are without entry_pc, but there is on pointer to were to find
the original info (which may not be present, if that unit did not have
debug info)
=
On 02/05/2022 09:56, Joost van der Sluis via Lazarusdev wrote:
Hi Martin, and all others,
Freepascal's joost/dwarfproperties branch has support for encoding
properties inside the Dwarf debug-info. Properties are basically
encoded as references to the underlying fields/methods.
Take this dwarfdump for example:
< 2><0x00ff> DW_TAG_member
DW_AT_name FProp
DW_AT_data_member_location len 0x0002: 0x2308:
DW_OP_plus_uconst 8
DW_AT_type
< 2><0x010d>
DW_AT_name DoubleProp
<0x019e>
DW_AT_accessibility DW_ACCESS_public
< 2><0x011e>
DW_AT_name SingleProp
<0x00ff>
<0x00ff>
DW_AT_accessibility DW_ACCESS_public
0x4230 is a property
0x3230 is a getter
0x3231 is a setter
The SingleProp property references the FProp field.
You can enable this with 'fpc -gw3 -godwarfproperties' using the
dwarfproperties branch.
I'm wondering how to handle this in fpDebug. I've did an attempt by
creating a symbol that symply forwards everything. But that does not
work very well
(https://gitlab.com/jvdsluis/lazarus-propdb/-/commit/d3853c23724ca63e561b82bc357bbf299fc3da1d)
Whay do you think is the best approach? Introduce a new class that
represents the property? Or add a lot of trickery to forward what is
necessary, but not everything (like the accesibility)
Regards,
Joost.
program dwarf_prop_test;
{$Mode objfpc}
uses unit1;
type
{ TBar }
TBar = class(TFoo)
private
FBarPropField: byte;
function GetBarPropGetter: byte;
function GetBarPropGetter2: byte;
function GetBarPropGetter3: byte;
published
property BarPropField: byte read FBarPropField;
property BarPropGetter: byte read GetBarPropGetter;
property BarPropGetter2: byte read GetBarPropGetter2;
property BarPropGetter3: byte read GetBarPropGetter3;
end;
{ TSome }
TSome = class(
Re: [fpc-devel] Cocoa and NOT relocatable
On 08/06/2023 19:59, Giuliano Colla via fpc-devel wrote: Il 08/06/23 18:40, Martin Frb via fpc-devel ha scritto: It seems that on Cocoa an exe is by default relocatable. At least a basic test shows that dumping a stack at runtime for each run (no new compile) gives new addresses. Fpc 3.2.2 Is there a way to turn this off? (some flag to pass to the linker?) AFAIK there's no way. It's a feature deep in the way the OS handles memory. In a multiprogramming environment any executable must be by definition relocatable, because at each run it must fit in a free area of memory. So the OS has two choices. Either the executable is not relocatable, and you trick it by altering the Memory Management Unit tables to map its virtual fixed addresses to any free memory area, or you make it relocatable, loose a little time when loading to locate it, and do not tamper with MMU mapping tables. It's a system design choice. Great... Yes, it is an important security feature. But a show stopper for people who need to debug. https://forum.lazarus.freepascal.org/index.php/topic,63571.0.html 1) Afaik, FPC still can't resolve addresses with -gl (the line info unit, that produces nice dumps on other Platforms). 2) Users can't later resolve them either. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Cocoa and NOT relocatable
It seems that on Cocoa an exe is by default relocatable. At least a basic test shows that dumping a stack at runtime for each run (no new compile) gives new addresses. Fpc 3.2.2 Is there a way to turn this off? (some flag to pass to the linker?) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] $ZEROBASEDSTRINGS [[Re: DW_AT_external and other additions to FPC generated dwarf]]
On 28/03/2023 15:50, Martin Frb via fpc-devel wrote:
On 28/03/2023 15:03, Sven Barth via fpc-devel wrote:
Martin Frb via fpc-devel schrieb am
So., 26. März 2023, 16:50:
It also would fall short, if ever Fpc did what Delphi did:
{$ZEROBASEDSTRINGS }
Though, maybe that is a "wont ever happen".
FPC supports that directive since at least 3.2.0 (though apparently
it was forgotten to be documented in the New Features page).
It is also missing here
https://www.freepascal.org/docs-html/prog/progch1.html___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] $ZEROBASEDSTRINGS [[Re: DW_AT_external and other additions to FPC generated dwarf]]
On 28/03/2023 15:03, Sven Barth via fpc-devel wrote:
Martin Frb via fpc-devel schrieb am
So., 26. März 2023, 16:50:
It also would fall short, if ever Fpc did what Delphi did:
{$ZEROBASEDSTRINGS }
Though, maybe that is a "wont ever happen".
FPC supports that directive since at least 3.2.0 (though apparently it
was forgotten to be documented in the New Features page).
I thought I had seen it somewhere... Maybe forum mention. But then I
could only find it on a Delphi page.___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] DW_AT_external and other additions to FPC generated dwarf
On 26/03/2023 16:50, Martin Frb via fpc-devel wrote: On 26/03/2023 15:50, Florian Klämpfl via fpc-devel wrote: What about using DW_TAG_string_type for this? IIRC, when I implemented dwarf, it was not available/not supported, but fpdebug can do they. I am not sure about the status of GDB about it though :) It still needs to be added to fpdebug, but that will be easy. Whether it will be used or not... I added a basic version to FpDebug. Without DWARF-5, since I haven't even got test data for the basic DWARF 3/4 implementation. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is this supposed to work (generic)?
On 27/03/2023 22:59, Sven Barth via fpc-devel wrote: Am 26.03.2023 um 13:30 schrieb Martin Frb via fpc-devel: TSome = class; TSome = class(specialize GenLinkedList); The correct way to declare a generic linked list using classes is the following: === code begin === type generic TGenLinkedList = class Data: D; Next: specialize TGenLinkedList; end; TSome = specialize TGenLinkedList; === code end === Ok, but the forward declaration (which is the only working one of my examples) is also important. Not sure, why it needs the forward. After all, the forward also comes after the generic. generic TGenLinkedList = class Data: D; Next: C; end; TSome = class; TSome = class(specialize TGenLinkedList) other: boolean; procedure Foo; end; procedure TSome.Foo; begin Next.other := true; // Next must be type TSome, not just the specialized generic. end; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] DW_AT_external and other additions to FPC generated dwarf
On 26/03/2023 15:50, Florian Klämpfl via fpc-devel wrote:
Am 23.03.23 um 09:45 schrieb Martin Frb via fpc-devel:
It's a little hard to comment all at once, but at least I start with
one :)
4) "official" marker for string vs pchar vs array
What about using DW_TAG_string_type for this? IIRC, when I implemented
dwarf, it was not available/not supported, but fpdebug can do they. I
am not sure about the status of GDB about it though :)
That would work.
But it can't distinguish between strings of char or widechar. I.e. it
can only be used for short and long-string(ansi). But not WideString or
UnicodeString.
Only DWARF 5 introduces a "DW_AT_type" for DW_TAG_string_type that can
then define the base type for each char.
Ignoring gdb, fpc could add that for lower dwarf versions too.
It also would fall short, if ever Fpc did what Delphi did:
{$ZEROBASEDSTRINGS }
Though, maybe that is a "wont ever happen".
It still needs to be added to fpdebug, but that will be easy.
It is present in gdb sources, but I have no idea how well it will then work.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Is this supposed to work (generic)?
3.2.3 and 3.3.1 on Win 64bit Trying a generic linked list. So the specialized class must have an entry for the "next" element. And that entry is of the same type as the class itself. Now at first, this seems to be not possible using generics, because specialize does not allow to pass in the "partially done" class. (the 2 commented lines produce "Error: Illegal expression") Only it does work, if the class is forward declared. So is it supposed to work? And if it is in the last case, then what about the other two cases? program Project1; type generic GenLinkedList = class Data: D; Next: T; end; //TBar = specialize GenLinkedList; //TFoo = class(specialize GenLinkedList); TSome = class; TSome = class(specialize GenLinkedList); begin end. Btw, it is the same, if the linked list uses actual pointer. generic GenLinkedList = class type PT = ^T; public Data: D; NextPtr: PT; end; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] DW_AT_external and other additions to FPC generated dwarf
After the brief exchange on
https://gitlab.com/freepascal.org/fpc/source/-/issues/40208
There are various considerations (ideas/requests) to hopefully help
improve debugging experience.
I have recently added 3 issues, but there is more. And I wanted to add a
bit of background here, since it is not all black and white.
1) Scoped Enums https://gitlab.com/freepascal.org/fpc/source/-/issues/40208
2) Unit Search order
https://gitlab.com/freepascal.org/fpc/source/-/issues/40209
3) DW_AT_external for types
https://gitlab.com/freepascal.org/fpc/source/-/issues/40210
4) "official" marker for string vs pchar vs array
5) Duplicated (artificial) types under Windows
5a) Missing address for class methods
6) "var param" for function calls / managed param
...
---
1) is simple to reason (IMHO)
There is an example in sysutils:
{$SCOPEDENUMS OFF}
TUseBoolStrs = (False, True);
If the debugger reads this, before getting to the definition of the
"True" (boolean), then expressions could fail if they contain the bool
constants true/false.
---
2) is required for looking up global vars.
A global var of the same name can exist in different units.
If paused on some code
if GlobalFoo > 5 then
The debugger needs to work out which GlobalFoo that is.
2) May or may not have an impact on type lookups. See 3.
---
3) DW_AT_external (or visibility) for types
After reconsidering, that one is actually more debatable. But IMHO still
useful.
unit foo;
interface
implementation
type PCHAR = ^widechar; // does not want to be seen outside this unit.
Granted this is not the most likely case to happen. But it may happen.
At first types seem to be save-ish. If a variable is declared in the
current unit (or otherwise found in the correct unit, according to "unit
search order", then the debug info of that variable points to the
correct type.
No ambiguity, not even with global types.
The issue occurs, when a user writes a watch, using type casts with
global types (that aren't from the current unit).
pchar(foo)
pinteger(foo) // this one can be ^smallint from unit system,
though that is not a implementation vs interface
TForm1(Sender)
In each case the debugger needs to find the correct type (if more that
one exists). And in each case, that is never 100% accurate, unless only
one type exists.
But imho can still benefit from the difference between implementation
and interface. Unless fully qualified, the user is unlikely to want the
above "pchar=^widechar" from some unit (maybe not even known to him).
As a side note, initially I thought that once unit-search-order is
known, the issue would be solved for good. But it wont. For
"TForm1(Sender)": "Sender: TControl" can be in units that do not use
"unit1". Yet the user would expect the debugger to find it.
And (on windows) a "uses unit1; var TempForm: TForm1" copies the
definition of "TForm1" into that unit. In that case the debugger will
always think as "TForm1" to belong to that unit. Which will likely be
correct, while paused in that unit, but may not be correct, if paused in
another unit, and just searching for the global definition of "TForm1".
So in the end the debugger will need to deal with the possibility of
ambiguity.
=> if that includes "types from implementation" is therefore not so big
of an issue. (still might be useful).
---
4) "official" marker for string vs pchar vs array
Not sure if that is reported already. Depending on dwarf version
"string" (ansistring) is a pointer (either TAG pointer/reference or
location expression) to
- char (dwarf 2)
- array of char (dwarf 3)
Currently for dwarf 2, the debugger can't tell the difference. If the
user says: foo[1]
The debugger does not know, if the first or second char is meant (0 or 1
based index)
With dwarf 3 the difference would be in the display format "('a', 'b',
'c') vs 'abc'.
But currently the debugger (fpdebug) can tell the difference, because
fpc has a tiny difference in how it encodes the "stride".
That is obviously an implementation detail, and not very future proof.
Therefore an "official" marker would be nice.
- it appears there is none in dwarf
- it could be a custom addition to dwarf
- documenting an "implementation detail" (such as the stride), so
fpdebug can safely rely on it.
---
5) Duplicated (artificial) types under Windows
As mentioned, declaring
var foo: TStringList
copies the type definition of TStringList to that unit (Windows only),
on Linux there is a cross compilation unit reference (well at least, if
the source unit has debug info, otherwise IIRC it also is a copy).
Maybe those copies should be marked DW_AT_artificial ?
From DWARF
>> A compiler may wish to generate debugging information entries for
objects or types that were not actually declared in the source of the
application
>> Any debugging information entry representing the declaration of an
object or type artificially gen
Re: [fpc-devel] Bug in 3.2.3 with corba interfaces
So it seems to be that topic https://forum.lazarus.freepascal.org/index.php?topic=39416.0 >> Is and As operators require that the interface has a GUID defined Only that in my case the compiler happily compile (MyObjec as TCorbaWithoutGUID).foo; Shouldn't that give an error? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Bug in 3.2.3 with corba interfaces
While I haven't got a simple example, by this time I am sure the issue is not in my code. (it's not online avail yet) I have a class, with 2 corba interfaces TIdeLocalsValue = class(TLocalsValue, TWatchAbleResultIntf, TWatchAbleDataIntf) ... end If I get an interface using (SomeVar as TWatchAbleDataIntf).Foo it either crashes, or calls the wrong method. If I swap the order of the interfaces in the declaration, then it works (but the other interface will fail). And yes, the object on which I work is of the correct class. And it is alive (not a dangling pointer). - I have tried to introduce a Base class, and move one Interface to that base class, but no luck ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Inconsistency in generics ?
On 03/03/2023 14:29, Sven Barth via fpc-devel wrote: All identifiers must be known when declaring a generic. In this case Trec1 is known thanks to the global type. Trec2 is not known (neither in its parent (at declaration time TBase1) nor globally) , so that will fail. When you specialize with TBase2 you change the parent thus a completely new scoping situation arises and Trec1 will no longer be the global Trec1, but that of TBase2. Considering how generics are implemented this is both as expected and as designed. Not to mention that using the generic parameter as parent is *not* officially considered a feature. It's simply not forbidden. I got to this only while generating code to feed code-tools. So it's not that I need it to be either way. I understand there is a set of rules to explain it all (or most of it, see "why" in code below). But the result of those rules are somewhat "interesting" It still feels strange It leads to "TRec1" being checked as something that it is not. If the "specialize" allows TRec1 to be something else (and something completely unrelated), then why does the generic check at all, that the non-specialized code compiles against the one seen by the generic? type generic TGen = class procedure x; end; procedure TGen.x; begin B.x := 1; // works, even so the compiler has no info what B might be (only that there is a name B) // B.y(); // then again, does not work - why? end; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Inconsistency in generics ?
To me the below behaviour appears inconsistent.
But before I file a bug, I want to double check, if maybe this is
intention
Tested with 3.2.3 and 3.3.1
Apparently
- when the generic TGen is compiled, it does check if a type "TRec1" and
"TRec2" is in scope at all.
- it verifies that the generic itself compiles with that type
- **but** then it allows that type to be replaced by another, if the
specialized param contains such another type
So if the specialized class, can have a type of it's own choosing for
"TRec1" then why insist that a random other type of that name exists
when the generic is declared.
(And why reject "TRec2" as it too could be available at the time of
specialization?)
Or should the specialized class "TClass1" use the global TRec1? and
ignore TBase2.TRec1 ?
program testgen;
{$mode objfpc}{$H+}
type
TRec1 = record r1: integer; end; // this will be used to check the
generic itself
TBase1 = class
end;
{ TBase2 }
TBase2 = class(TBase1)
public type
TRec1 = record r1_b2: integer; end; // this will be used in specialize
TRec2 = record r2_b2: integer; end;
end;
generic TGen = class(B)
f1: Trec1; // here TBase2.Rec is not known
//f2: Trec2; // Error: Identifier not found "Trec2"
procedure x;
end;
TClass1 = class(specialize TGen)
procedure Bar;
end;
procedure TGen.x; // neither works...
begin
//f1.r1 := 2; // fails when specialized
//f1.r1_b2 := 2; // fails for the generic
end;
procedure TClass1.Bar;
begin
f1.r1_b2 := 1; // This is TBase2.Rec, and compiles with 3.2.3 and 3.3.1
end;
begin
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Curious about the effect of all the new optimizations....
On 01/03/2023 14:22, J. Gareth Moreton via fpc-devel wrote:
On 01/03/2023 13:11, Martin Frb via fpc-devel wrote:
Hence testing back to 3.2.3 ( unfortunately 3.2.2 has a bug that
matters in this code)
Also, I didn't expect any huge diffs, just wanted to see if anything
can be noted at all. (and if lucky, in that test I run)
I did a test on a more limited scope (testing only a handful of
functions. That test runs 4 Min 20 sec under 3.2.3.
And 2 extra seconds with 3.3.1. But then I only had 2 sample runs
for each fpc version
2 seconds out of 4:20 is not conclusive unfortunately, unless you're
able to exactly control the machine state each time, which is next to
impossible in the modern day. I am curious of the slowdown though,
even if it is very slight.
It will be to much code to find it
It's looping and setting up different combinations of data/structures...
It is the test in ide/packages/idedebugger
subtest: TestWatchArrayStuct
(I did not check the others subtests, but this test is combining some of
the others...)
The diff also happened when I did (for some of the involved units / not
for all)
{$CodeAlign proc=32 loop=32}
But it could still be that some code got to an unfortunate alignment.
---
For more testing I would need to set up scripts, to compile and run
automatically with lots of settings (and then run over night, when
nothing else goes on).
Also find other PC with diff CPU
For now, I just wanted to do a quick test. (balance my interest with the
time I have...). So I wont set up in depth testing now.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Curious about the effect of all the new optimizations....
On 01/03/2023 12:25, J. Gareth Moreton via fpc-devel wrote: My peephole optimisations mostly save only a handful of cycles each time which probably won't add up to much for a relatively short test. The most major optimisation I can think of, although I'm not quite sure when it was merged, is the method of replacing divisions by a constant with an equivalent reciprocal multiplication. You'll see the biggest savings there. There's other difficulties like processors being intelligent with caching and out of order execution, for example, that are disguising some inefficiencies. And some seek only to reduce code size with no loss of speed. What are your timings like when compiling with COREAVX or COREAVX2? A couple of recent peephole optimizations make use of BMI1 and BMI2. I had -CpCOREAVX2 supplied. (my fpc is a good week old, so if recent is less than that...) I don't have many divisions in that code. Most of the good is going through big data in memory. So its possible that any gained processing speed, just has to wait for data to be fetched. I can't remember the proverb that Florian used, but it essentially boils down to very small changes, individually not amounting to much, but which accumulate into a noticable difference when in large numbers. Hence testing back to 3.2.3 ( unfortunately 3.2.2 has a bug that matters in this code) Also, I didn't expect any huge diffs, just wanted to see if anything can be noted at all. (and if lucky, in that test I run) I did a test on a more limited scope (testing only a handful of functions. That test runs 4 Min 20 sec under 3.2.3. And 2 extra seconds with 3.3.1. But then I only had 2 sample runs for each fpc version ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Curious about the effect of all the new optimizations....
On 01/03/2023 11:55, Adriaan van Os via fpc-devel wrote: That may have been "-Performance Matters- by Emery Berger". By I find it a nonsense video. Only that last year, I had some code where it happened to me. Some code (that had no change in itself, other than a routine above it (which was not part of the benchmark) had changed, and hence the tested code changed alignment. IIRC over 20% speed diff. Matched exactly what he described. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Curious about the effect of all the new optimizations....
On 01/03/2023 11:47, Bart via fpc-devel wrote: On Wed, Mar 1, 2023 at 11:33 AM Martin Frb via fpc-devel wrote: So for a while now fpc 3.3.1 receives new optimizations => which is great / big fan of it. And hence I thought, lets see how much of an impact they have. And in my test, they had none :( Optimizations beyond O2 (or even O1) most of the times do not make a difference for the average user. There is much randomness in the performance of an application caused by things you cannot control, which have more influence on the performance of the application I watched a video about this not so long ago (it was about optimization levels in gcc), which explained all this, but I'm unable to find that again and unanble to reproduce what was being said there. I know the video. Eyeballing and alignment issues were among the causes. For the latter I tried to see if codealign would have an effect. Though of course if it had, it be a lucky strike. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Curious about the effect of all the new optimizations....
So for a while now fpc 3.3.1 receives new optimizations => which is
great / big fan of it.
And hence I thought, lets see how much of an impact they have. And in my
test, they had none :(
Wondering if any one else has measured them?
My tests:
Win-10 64 bit
3.3.1 905c485ff413cd48f98891e2075c814759d0c6f1
3.2.3 2022-02-04
both compilers with each O2 and O4
Using the testcase for FpDebug (which runs a decent spread of code).
Testcase with O2 and O3
And I got no noticeable difference.
I also tried {$CodeAlign proc=32 loop=32} for O2 (test and fpc), also no
diff.
O2 / fpc: o2 323
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug : 22.406
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug : 22.063
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug : 22.609
O2 / fpc: o2 331
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug : 22.251
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug : 22.031
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug : 21.531
O3 / fpc: o2 323
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug : 22.687
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug : 22.281
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug : 22.469
O3 / fpc: o2 331
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug : 23.203
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug : 22.250
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug : 22.140
O3 / fpc: o4 323
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug : 23.063
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug : 22.250
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug : 22.875
O3 / fpc: o4 331
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug : 22.577
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug : 22.094
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug : 22.235
{$CodeAlign proc=32 loop=32}
O2 / fpc: def 323
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug : 22.453
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug : 22.328
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug : 22.656
O2 / fpc: def 331
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug : 22.079
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug : 22.234
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug : 21.984
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] FPC 3.3.1 crash when getting interface from object
I don't currently have many details. (The code in question has been working on older 3.3.1, and still works on 3.2.3 and before) I included various details, but in the end it may be a peephole issues in "GetInterfaceByStr" ==> So probably skip ahead to the asm code below. The code call a method expecting an interface, and providing an instance as param. The instance is of a class implementing the interface. The class uses generics as base, including generics (for the interface) for the expected param in the called method. I tested with O2 and O4 (for my code ) ===> and for fpc/rtl: -CX -gl -gw3 -O-1 rev e84e0a16e13a4b73192edafd2aa356254dc2ac88 The line that fails is: function TObject.GetInterfaceByStr(const iidstr : shortstring;out obj) : boolean; ... if result and Assigned(IEntry^.IID) and (IEntry^.IType in [etStandard, etFieldValue]) then IInterface(obj)._AddRef; At the time Result = true IEntry^ = ( IIDREF: ^PGUID(nil); VTABLE: $000100719838^: ; IOFFSET: 32; IOFFSETASCODEPTR: $0020^: ; IIDSTRREF: $0001007103E8^^: $0001007103E0^: ''; ITYPE: ETSTANDARD) IEntry^.IID gets function tinterfaceentry.GetIID: pguid; begin if Assigned(IIDRef) then GetIID:=IIDRef^ else GetIID:=Nil; The interface for the param is "CORBA". (so IIDRef should be nil, according to comments in the code) Generated asm (as reported by GDB) / Crash line is marked < => Something seems strange. There is a "cmp" without any conditional after it? ..\inc\objpas.inc:922 000100012293 807de400 cmpb $0x0,-0x1c(%rbp) 000100012297 7441 je 0x1000122da 000100012299 488b45d8 mov -0x28(%rbp),%rax // EAX = The address pointing to IEntry ..\inc\objpas.inc:924 00010001229D 31c9 xor %ecx,%ecx ..\inc\objpas.inc:922 00010001229F 48833800 cmpq $0x0,(%rax) 0001000122A3 488b00 mov (%rax),%rax // EAX = The first qword in the record. That is RAX = IEntry^.IIDRef 0001000122A6 488b00 mov (%rax),%rax // << RAX = 0x0 0001000122A9 488b45d8 mov -0x28(%rbp),%rax 0001000122AD 480f44c1 cmove %rcx,%rax 0001000122B1 4885c0 test %rax,%rax 0001000122B4 7424 je 0x1000122da 0001000122B6 488b45d8 mov -0x28(%rbp),%rax 0001000122BA 8b4020 mov 0x20(%rax),%eax 0001000122BD 85c0 test %eax,%eax 0001000122BF 7405 je 0x1000122c6 0001000122C1 83f803 cmp $0x3,%eax 0001000122C4 7514 jne 0x1000122da ..\inc\objpas.inc:923 #0 TOBJECT.GETINTERFACEBYSTR(TOBJECT($0CF471C0), '', 0) at c:\FPC\fpc_3.3.1\source\rtl\inc\objpas.inc:922 #1 TOBJECT.GETINTERFACE(TOBJECT($0CF471C0), '', 0) at c:\FPC\fpc_3.3.1\source\rtl\inc\objpas.inc:928 #2 fpc_class_as_corbaintf(POINTER($0CF471C0), '') at c:\FPC\fpc_3.3.1\source\rtl\inc\objpas.inc:262 #3 TINTERNALDBGMONITORBASE$3$CRC97C7D6C3_CRC46A2B365.SETSUPPLIER(TINTERNALDBGMONITORBASE$3$CRC97C7D6C3_CRC46A2B365($0CF471C0), Failed to read data from register) at lazdebuggertemplate.pas:112 #4 TTESTDBGDEBUGGER.INITDEBUGGERMONITORS(TTESTDBGDEBUGGER($0CF471C0), Failed to read data from register) at B:\lazarus_main\components\lazdebuggers\lazdebugtestbase\ttestdbgexecuteables.pas:399 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] threads vs widestringmanager / crash
On 21/12/2022 11:37, Marc Weustink via fpc-devel wrote: On 20-12-2022 21:12, Sven Barth via fpc-devel wrote: So the only logical solution is to stop the offending thread from executing or not to have it call InitThread() while the initialization section of the System unit is still running. The former might have unintended consequences (e.g. not being able to debug the unit initialization) while the later might work in most cases as long as that remote thread doesn't need to execute code that relies on InitThread(). The latter may be the best solution. Skip any rtl call when a thread attaches during initialization. In normal cases this will only be triggered when a debugger attaches. It usually only forces a breakpoint, so no fully initialized rtl is needed. Ondrey When you got the issue, did you: - Use FpDebug? - Lazarus 2.3 - Run/Debug - But *not* press the "pause" button? Because if so, the debugger should not have sent any DebugBreak. Unless Windows itself injects threads, if an exe is started with "poDebugProcess". So maybe something else is injecting threads... And the reason it happens (to be observed) only in the debugger is that the timing changes. Ondrey, if the above (FpDebug, not pressed "pause") applies, can you test the following: Modify the system unit, and in the "initialization" section, insert some "sleep(250);" between statements (downto after InitSystemThreads) Then run without debugger. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
