from:"Martin"


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=false

I didn't understand the reasons behind (but then I am not familiar with
the FPC codebase).

I do now get some guesses as to why...

-
But anyway, I started my own attempt based on that.
https://gitlab.com/martin_frb/fpc-src/-/compare/main...martin-dwarf-properties?from_project_id=28644964=false

The first problem is getting labels for items that need to be referenced.

2a267440b240be3aa99d0c14fd6c8dcf90a27f99
For procedures this is explained in the first commit => they currently
have an (possible intentional) unbalanced dbg_state_writing.

Requiring them to have a label, conflicts with that.
I welcome feedback on the suggestions in my commit message.

19e6b4fea54b85df1ad8df221947231d01d98bb9
Just completing the above, and write the labels.

959566d705d6a464b3076a97ddaa8213c9d9ec9f
Same problem for DW_TAG_MEMBER
My "workaround" is certainly wrong. But currently there is no SYM.
How can I get labels for it?
Such as that they also work, if the field is in the parent, in a diff
unit => which on linux requires a global label, since the declaration is
NOT copied into the current unit.

50f7d0d53a20cef541f87b474a7b8cc39558808d
Write the basic info.
Currently only works if the property field/getter is in the same object
(or base class), but not if it is in a record belonging to the object.
The latter requires the structure address to be also written, and
resolving the record to the field...

But before I go and spent time on that, I would like to first resolve
all the issues that already exist.

-
Using -godwarffpdbg would also allow for this:
https://gitlab.com/martin_frb/fpc-src/-/compare/main...martin-entry-pc?from_project_id=28644964=false

Which makes sure there is an address for each of the functions that need
to be called.

-
Test implementation in Lazarus
https://gitlab.com/martin_frb/lazarus/-/commits/fpdebug-godwarfproperties

properties with getters aren't called yet. It shows the getter, as if it
was an event variable.

But if the getter has an address, it can be called by adding "()" (and
enabling function eval).

At least for datatypes supported in function calls.

Looking forward to some feedback.
Martin

___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] wrong result for abs(low(int64))

2024-04-04 Thread Martin Frb via fpc-devel


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

2024-04-04 Thread Martin Frb via fpc-devel


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

2024-03-20 Thread Martin Frb via fpc-devel


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

2024-03-19 Thread Martin Frb via fpc-devel


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

2024-03-19 Thread Martin Frb via fpc-devel


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

2024-02-22 Thread Martin Frb via fpc-devel


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

2024-02-17 Thread Martin Frb via fpc-devel

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"

2024-02-14 Thread Martin Frb via fpc-devel


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?

2024-02-13 Thread Martin Frb via fpc-devel


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;

2024-02-10 Thread Martin Frb via fpc-devel


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

2024-01-31 Thread Martin Frb via fpc-devel


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

2024-01-24 Thread Martin Frb via fpc-devel


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

2024-01-11 Thread Martin Frb via fpc-devel


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

2024-01-11 Thread Martin Frb via fpc-devel


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

2024-01-11 Thread Martin Frb via fpc-devel


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 ?

2023-12-29 Thread Martin Frb via fpc-devel


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

2023-12-29 Thread Martin Frb via fpc-devel


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

2023-12-09 Thread Martin Frb via fpc-devel


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

2023-12-09 Thread Martin Frb via fpc-devel


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

2023-12-07 Thread Martin Frb via fpc-devel


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

2023-12-07 Thread Martin Frb via fpc-devel


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.1/source/rtl/units/x86_64-linux -FE. 
-FUunits/x86_64-linux -Cg -Fl/usr/lib/gcc/x86_64-redhat-linux/13 
-dx86_64 -dRELE

[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

2023-11-10 Thread Martin Frb via fpc-devel


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

2023-11-10 Thread Martin Frb via fpc-devel


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

2023-11-09 Thread 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)?

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

2023-11-09 Thread Martin Frb via fpc-devel


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

2023-11-09 Thread Martin Frb via fpc-devel


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=

2023-10-06 Thread Martin Frb via fpc-devel


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=

2023-10-06 Thread Martin Frb via fpc-devel


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

2023-09-26 Thread Martin Frb via fpc-devel


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

2023-09-04 Thread Martin Frb via fpc-devel

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

2023-08-14 Thread Martin Frb via fpc-devel


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

2023-08-14 Thread Martin Frb via fpc-devel

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

2023-07-23 Thread Martin via fpc-devel


On 20/07/2023 18:41, Martin Frb via fpc-devel wrote:
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"?


Actually my previous example was not even the generic case.

Passing any variable that is allocated on the Heap (a field of an 
instance, an element of an array) as a "var param" has the danger that 
it can be freed.


And yes, it should be obvious. If you intent to write to a variable, you 
must not destroy it.
However, you must also be aware, that in case of an array, if you just 
resize it, it may move => yet your var param will not follow that move.


I think it may be "interesting" enough to deserve a small note.

--
The below should brinte 200 to 209.
But it does print a 999 in the middle.




program Project1;
{$mode objfpc}

var x,y: array of integer;
  i: Integer;

procedure foo(var a: integer);
var
  j: Integer;
begin
  x := nil;
  SetLength(y, 10);
  for j := 0 to 9 do y[j] := 200+j;

  a := 999;
end;

begin
  SetLength(x, 10);
  for i := 0 to 9 do x[i] := 100+i;
  foo(x[5]);
  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] Maybe room for better documentation? open array as var param

2023-07-20 Thread Martin Frb via fpc-devel


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

2023-07-20 Thread Martin Frb via fpc-devel

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?

2023-07-19 Thread Martin Frb via fpc-devel


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?

2023-07-18 Thread Martin Frb via fpc-devel


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] cthreads and fpc.cfg?

2023-07-18 Thread Martin via fpc-devel


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.



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

2023-07-04 Thread Martin Frb via fpc-devel

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:

Re: [fpc-devel] Cocoa and NOT relocatable

2023-06-08 Thread Martin Frb via fpc-devel


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

2023-06-08 Thread Martin Frb via fpc-devel


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

2023-03-28 Thread Martin Frb via fpc-devel


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

2023-03-28 Thread Martin Frb via fpc-devel


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

2023-03-28 Thread Martin Frb via fpc-devel


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

2023-03-27 Thread Martin Frb via fpc-devel


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

2023-03-26 Thread Martin Frb via fpc-devel


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

2023-03-26 Thread Martin Frb via fpc-devel


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

2023-03-23 Thread Martin Frb via fpc-devel

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

Re: [fpc-devel] Bug in 3.2.3 with corba interfaces

2023-03-18 Thread Martin Frb via fpc-devel


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

2023-03-18 Thread Martin Frb via fpc-devel

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 ?

2023-03-03 Thread Martin Frb via fpc-devel


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 ?

2023-03-03 Thread Martin Frb via fpc-devel


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

2023-02-05 Thread Martin Frb via fpc-devel

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

2022-12-21 Thread Martin Frb via fpc-devel


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

Re: [fpc-devel] threads vs widestringmanager / crash

2022-12-20 Thread Martin via fpc-devel


Ok, I don't know too much about the whole initialization
But on the off chance of triggering some ideas, I throw in a couple of 
my thoughts


On 19/12/2022 07:42, Sven Barth wrote:

Am 07.07.2018 um 15:04 schrieb Martin:
So (guessing) the original issue may be due to the debugger. The 
debugger interrupts the target early on. And that does create a 
thread in the target.
If such an external thread happens, would fcp execute the code in 
question?


This is likely to be the cause, cause the EXEC_TLS_CALLBACK is 
executed by Windows for every thread that is started for an 
application. And if the debugger triggers the start of a thread...


Maybe, maybe not always? But, yes at least in the case that I documented 
in 2018: 
https://lists.freepascal.org/pipermail/fpc-devel/2018-July/039374.html


Yet in the system unit:

initialization
.
  if not Assigned(CurrentTM.BeginThread) then
  begin
    InitHeap;
    InitSystemThreads;
  end;
  SysInitExceptions;
  initunicodestringmanager;
  InitWin32Widestrings;

So the WS-Mgr is only assigned after InitSystemThreads => which sets up  
RelocateThreadVar => which can call InitThread.


So order may need to be changed there (if that is possible).
Of course, the case where EXEC_TLS_CALLBACK calls InitThread remains.

A lot of the WS-Mgr init is assigning pointers to the correct procedure.
So if InitThread sees that this has not been done yet, InitThread could 
call those.
Even if 2 threads (main and the early thread) both assign values to the 
pointer, they assign the same value, and so that should not do harm.
Of course the thread init must not change the value, once it was set by 
the main thread, in case usercode assigned a diff value (so maybe in 
ThreadInit, use Interlocked)


This may mean to break "InitWin32Widestrings" into 2 parts, because it 
also prepares some tables.

But those are not needed for "GetStandardCodePageProc"

So if the setting of the codepage related proc pointers are moved to a 
separate init-method, then that can be called (if needed) by InitThread.


--
Or maybe if EXEC_TLS_CALLBACK calls InitThread, it can do the (partial) 
init of WidestringMgr before? (if the order in the initialization 
section can be changed to do the same?)


--
I am not sure if this code needs to worry about any of the other WS-Mgr 
functions.
Any thread that early is not started by Pascal code (neither user, nor 
rtl). It will be a thread working some kernel proc. And that shouldn't 
access the WS-Mgr?



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] InitHeap in TLS_Callback [[Re: threads vs widestringmanager / crash]]

2022-12-20 Thread Martin via fpc-devel


On 20/12/2022 15:08, Martin wrote:

Ok, I don't know too much about the whole initialization
But on the off chance of triggering some ideas, I throw in a couple of 
my thoughts


On 19/12/2022 07:42, Sven Barth wrote:


This is likely to be the cause, cause the EXEC_TLS_CALLBACK is 
executed by Windows for every thread that is started for an 
application. And if the debugger triggers the start of a thread...


Maybe, maybe not always? But, yes at least in the case that I 
documented in 2018: 
https://lists.freepascal.org/pipermail/fpc-devel/2018-July/039374.html


While I just looked through that code, I came to think there may be yet 
another issue.


If a thread is started, that can call EXEC_TLS_CALLBACK.
And EXEC_TLS_CALLBACK  can call InitHeap (in DLL_PROCESS_ATTACH) before 
the main thread has run InitHeap.


But InitHeap does not seem to be threadsafe.

InitHeap itself does probably work if it runs overlapping. But, if one 
thread already goes into using the heap (e.g. allocating) while the 
other still is in InitHeap... That likely does not go well.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Experimentation: "Branch stitching"


On 28/11/2022 16:37, Martin Frb via fpc-devel wrote:


"11.3μop cache"


Apart from the qop cache there is the normal loading into the cache.

I must admit I am not sure on the exact workings, but wasn't there 
something like loading entire cachelines?  If that is so (not sure), 
then of course moving other code in between means potentially pushing 
the current code out of the same cache line?


Then the decision needs information which code is executed more 
often/likely.
(Also in that case I don't know if the conditional branch could be 
negated (be vs bne / bg <> ble ...) without affecting the branch 
predictor? (leaving the order, but dropping the the jmp).


Of course there may also be the question of the distance, and which jump 
/ conditional jump takes what byte size for the distance (Again I 
don't know)___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Experimentation: "Branch stitching"


On 28/11/2022 16:19, J. Gareth Moreton via fpc-devel wrote:
I admit I can be disorganised sometimes and lose documents, so I 
apologise if you have sent them already and I mislaid them in my mess 
of a directory tree.  Believe me though, I want to swallow all of this 
up if it means squeezing out every cycle I can out of the generated 
machine code!


Curious to know... at which point did it become favourable to do a 
32-byte align rather than a 16-byte align on x86 processors? Should 
the compiler start favouring 32-byte aligns for loops, say?


https://www.agner.org/optimize/optimizing_assembly.pdf

"11.3μop cache"

I couldn't find the 32byte align in that doc though. I must have picked 
that up elsewhere. (I think).
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Experimentation: "Branch stitching"


On 28/11/2022 14:32, J. Gareth Moreton via fpc-devel wrote:

On 28/11/2022 12:59, Martin Frb via fpc-devel wrote:

Well first of all, you didn't move the balign in front of .Lj732


I do move the alignment hints, but if the label becomes dead (due to 
the zero-distance jump being 'collapsed'), the alignment hint gets 
removed.  It's an experiment in progress.


Ah, yes right.
Anyway this may be more of a 32 byte thing, and the 16 byte align is at 
best a 50/50 game


I once had a better source on the topic (also it might be in the pdf I 
once sent) but for now:

https://superuser.com/questions/1368480/how-is-the-micro-op-cache-tagged


Each 32B window (from the instruction cache) is mapped into the uop cache
(in case of an outer loop) Due to the size of that cache depending what 
else is executed, uops may or may not be cached (also only matters if 
the moved block is (inside a loop) frequently entered).
But ultimately, the 16 bytes align are not meant for that. Though if a 
user used a directive to set a 32byte align => then that may matter.



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Experimentation: "Branch stitching"