Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2019-08

ppc64le ABI problem

19 messages · 6 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Unknown author

Hello,

while examining a crash when running Lazarus on ppc64le, I found the following issue in function calls.

Calls to functions with more than eight parameters seem to be implemented differently from how gcc does it in a C program.

gcc uses the memory location 96(r1) for the ninth parameter, but FPC uses 112(r1).

Therefore, calls to XGetWindowProperty crash. This function has 12 parameters. gcc puts the four last ones into 96(r1), 104(r1), 112(r1), 120(r1), and FPC into 112(r1), 120(r1), 128(r1), 136(r1).

What can be done about this?

I also noticed that the "file" command in Linux mentioned an additional property of the linked C program I wrote for testing: "for GNU/Linux 3.10.0"

The FPC program did not have this tag.

The complete "file" outputs are:

a.out: ELF 64-bit LSB shared object, 64-bit PowerPC or cisco 7500, version 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.2, BuildID[sha1]=6c5d2b5c7408e74eeda95fbf8d120fe8de0f2f30, for GNU/Linux 3.10.0, with debug_info, not stripped

minimalxcrash: ELF 64-bit LSB executable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.2, with debug_info, not stripped

Hoping my find will be useful,
Best wishes,
Tobias Giesen

Reply by email

Florian Klämpfl
to Unknown author

Am 26. August 2019 00:59:16 schrieb

Show quoted text 21 lines
Hello, while examining a crash when running Lazarus on ppc64le, I found the following issue in function calls. Calls to functions with more than eight parameters seem to be implemented differently from how gcc does it in a C program. gcc uses the memory location 96(r1) for the ninth parameter, but FPC uses 112(r1). Therefore, calls to XGetWindowProperty crash. This function has 12 parameters. gcc puts the four last ones into 96(r1), 104(r1), 112(r1), 120(r1), and FPC into 112(r1), 120(r1), 128(r1), 136(r1). What can be done about this?

Try to change the 48 in fpc/compiler/powerpc64/cpupara.pas line to 32 as a temporary test.

Show quoted text 32 lines
I also noticed that the "file" command in Linux mentioned an additional property of the linked C program I wrote for testing: "for GNU/Linux 3.10.0" The FPC program did not have this tag. The complete "file" outputs are: a.out: ELF 64-bit LSB shared object, 64-bit PowerPC or cisco 7500, version 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.2, BuildID[sha1]=6c5d2b5c7408e74eeda95fbf8d120fe8de0f2f30, for GNU/Linux 3.10.0, with debug_info, not stripped minimalxcrash: ELF 64-bit LSB executable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.2, with debug_info, not stripped Hoping my find will be useful, Best wishes, Tobias Giesen _______________________________________________ fpc-pascal maillist - https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Reply by email

Sven Barth
to Florian Klämpfl

Florian Klämpfl schrieb am Mo., 26. Aug. 2019,
14:01:

Show quoted text 28 lines
Am 26. August 2019 00:59:16 schrieb > Hello, > > > while examining a crash when running Lazarus on ppc64le, I found the > following issue in function calls. > > > Calls to functions with more than eight parameters seem to be > implemented differently from how gcc does it in a C program. > > > gcc uses the memory location 96(r1) for the ninth parameter, but FPC > uses 112(r1). > > > Therefore, calls to XGetWindowProperty crash. This function has 12 > parameters. gcc puts the four last ones into 96(r1), 104(r1), 112(r1), 120(r1), > and FPC into 112(r1), 120(r1), 128(r1), 136(r1). > > > What can be done about this? Try to change the 48 in fpc/compiler/powerpc64/cpupara.pas line to 32 as a temporary test.

Line 302 in case anyone is wondering (thankfully that's the only "48" in that fike (plus its preceeding comment) ^^')

Regards,
Sven

Reply by email

Florian Klämpfl
to Sven Barth
Sven Barth wrote 43 lines
Florian Klämpfl schrieb am Mo., 26. Aug. 2019, 14:01: > Am 26. August 2019 00:59:16 schrieb > >> Hello, >> >> >> >> >> while examining a crash when running Lazarus on ppc64le, I found the >> following issue in function calls. >> >> >> >> >> Calls to functions with more than eight parameters seem to be >> implemented differently from how gcc does it in a C program. >> >> >> >> >> gcc uses the memory location 96(r1) for the ninth parameter, but FPC >> uses 112(r1). >> >> >> >> >> Therefore, calls to XGetWindowProperty crash. This function has 12 >> parameters. gcc puts the four last ones into 96(r1), 104(r1), 112(r1), > 120(r1), >> and FPC into 112(r1), 120(r1), 128(r1), 136(r1). >> >> >> >> >> What can be done about this? > > Try to change the 48 in fpc/compiler/powerpc64/cpupara.pas line to 32 as a > temporary test. Line 302 in case anyone is wondering (thankfully that's the only "48" in that fike (plus its preceeding comment) ^^')

Indeed :-) If it works, it must be made dependent on the target ABI.

Reply by email

Unknown author
to Florian Klämpfl

Hello,
many thanks, I will try it!

I haven't compiled FPC for ppc64le myself so it can take a few days but I will let you know about the result.

Cheers,
Tobias

----

Show quoted text 52 lines
Am 26. August 2019 14:08:39 schrieb Sven Barth via fpc-pascal : > Florian Klämpfl schrieb am Mo., 26. Aug. 2019, > 14:01: > >> Am 26. August 2019 00:59:16 schrieb >> >>> Hello, >>> >>> >>> >>> >>> while examining a crash when running Lazarus on ppc64le, I found the >>> following issue in function calls. >>> >>> >>> >>> >>> Calls to functions with more than eight parameters seem to be >>> implemented differently from how gcc does it in a C program. >>> >>> >>> >>> >>> gcc uses the memory location 96(r1) for the ninth parameter, but FPC >>> uses 112(r1). >>> >>> >>> >>> >>> Therefore, calls to XGetWindowProperty crash. This function has 12 >>> parameters. gcc puts the four last ones into 96(r1), 104(r1), 112(r1), >> 120(r1), >>> and FPC into 112(r1), 120(r1), 128(r1), 136(r1). >>> >>> >>> >>> >>> What can be done about this? >> >> Try to change the 48 in fpc/compiler/powerpc64/cpupara.pas line to 32 as a >> temporary test. > > Line 302 in case anyone is wondering (thankfully that's the only "48" in > that fike (plus its preceeding comment) ^^') Indeed :-) If it works, it must be made dependent on the target ABI. _______________________________________________ fpc-pascal maillist - https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Kind Regards,
Tobias Giesen

Super Flexible Software GmbH & Co. KG
Buddenstr. 29-31
48143 Münster, Germany
www.superflexible.com
www.tgtools.com

----------------------------------------------------------- Registered at register court Münster as HRA 9716
Liability / general partner: TGTools GmbH
Registered at register court Münster as HRB 17763 Directors: Tobias Giesen and Claudia Giesen

Reply by email

Unknown author
to Florian Klämpfl: Indeed :-) If it works, it must be made dependent on the target ABI.

Hello,

trying to recompile now ... since ppc64le support is not in 3.0.4, I suppose I need to use a more recent version to compile it. So there is no advantage in cross-compiling and I might as well try it with the latest native fpc compiler?

So I need to fix compiler errors myself, is that correct, such as this: sysosh.inc(19,1) Error: Forward type not resolved "Boolean8" bugs.freepascal.org/view.php?id=35676

I wonder how the precompiled FPC for ppc64le is made, if trunk cannot compile itself?

Cheers,
Tobias

Reply by email

Sven Barth
to Unknown author

schrieb am Mo., 26. Aug. 2019, 19:53:

Show quoted text 14 lines
Hello, trying to recompile now ... since ppc64le support is not in 3.0.4, I suppose I need to use a more recent version to compile it. So there is no advantage in cross-compiling and I might as well try it with the latest native fpc compiler? So I need to fix compiler errors myself, is that correct, such as this: sysosh.inc(19,1) Error: Forward type not resolved "Boolean8" bugs.freepascal.org/view.php?id=35676 I wonder how the precompiled FPC for ppc64le is made, if trunk cannot compile itself?

FPC 3.0.4 is still the latest release and thus currently the only supported compiler. In case of ppc64le you need to indeed cross compile though as long as you have the binutils it's as simple as

make clean all CPU_TARGET=ppc64le BINUTILSPREFIX=ppc64le-elf- FPMAKEOPT="-T N" - j N

Whereby you need to adjust BINUTILSPREFIX to whatever prefix your binutils have and N to e.g. your number of cores.

Regards,
Sven

Reply by email

Jonas Maebe
to Florian Klämpfl: Indeed :-) If it works, it must be made dependent on the target ABI.
Florian Klämpfl wrote 12 lines
Am 26. August 2019 14:08:39 schrieb Sven Barth via fpc-pascal : > Florian Klämpfl schrieb am Mo., 26. Aug. 2019, > 14:01: > >> Try to change the 48 in fpc/compiler/powerpc64/cpupara.pas line to 32 as a >> temporary test. > > Line 302 in case anyone is wondering (thankfully that's the only "48" in > that fike (plus its preceeding comment) ^^') Indeed :-) If it works, it must be made dependent on the target ABI.

It's indeed like that, see section 2.2.2 of
https://openpowerfoundation.org/wp-content/uploads/2016/03/ABI64BitOpenPOWERv1.1_16July2015_pub4.pdf

Jonas

Reply by email

Florian Klaempfl
to Jonas Maebe
Jonas Maebe wrote 16 lines
On 26/08/2019 14:22, Florian Klämpfl wrote: > Am 26. August 2019 14:08:39 schrieb Sven Barth via fpc-pascal : > >> Florian Klämpfl schrieb am Mo., 26. Aug. 2019, >> 14:01: >> >>> Try to change the 48 in fpc/compiler/powerpc64/cpupara.pas line to 32 as a >>> temporary test. >> >> Line 302 in case anyone is wondering (thankfully that's the only "48" in >> that fike (plus its preceeding comment) ^^') > > Indeed :-) If it works, it must be made dependent on the target ABI. It's indeed like that, see section 2.2.2 of https://openpowerfoundation.org/wp-content/uploads/2016/03/ABI64BitOpenPOWERv1.1_16July2015_pub4.pdf

Yes, I checked the docs as well :) I don't know though why it is only 32 for elf_abi_v2 ...

Reply by email

Jonas Maebe
to Florian Klaempfl
Florian Klaempfl wrote 20 lines
Am 26.08.2019 um 20:52 schrieb Jonas Maebe: > On 26/08/2019 14:22, Florian Klämpfl wrote: >> Am 26. August 2019 14:08:39 schrieb Sven Barth via fpc-pascal : >> >>> Florian Klämpfl schrieb am Mo., 26. Aug. 2019, >>> 14:01: >>> >>>> Try to change the 48 in fpc/compiler/powerpc64/cpupara.pas line to 32 as a >>>> temporary test. >>> >>> Line 302 in case anyone is wondering (thankfully that's the only "48" in >>> that fike (plus its preceeding comment) ^^') >> >> Indeed :-) If it works, it must be made dependent on the target ABI. > > It's indeed like that, see section 2.2.2 of > https://openpowerfoundation.org/wp-content/uploads/2016/03/ABI64BitOpenPOWERv1.1_16July2015_pub4.pdf Yes, I checked the docs as well :) I don't know though why it is only 32 for elf_abi_v2 ...

It's because the other ABIs also provide space for a compiler and linker-specific slot:
https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#STACK

Jonas

Reply by email

Jonas Maebe
to Jonas Maebe
Jonas Maebe wrote 25 lines
On 26/08/2019 20:54, Florian Klaempfl wrote: > Am 26.08.2019 um 20:52 schrieb Jonas Maebe: >> On 26/08/2019 14:22, Florian Klämpfl wrote: >>> Am 26. August 2019 14:08:39 schrieb Sven Barth via fpc-pascal : >>> >>>> Florian Klämpfl schrieb am Mo., 26. Aug. 2019, >>>> 14:01: >>>> >>>>> Try to change the 48 in fpc/compiler/powerpc64/cpupara.pas line to 32 as a >>>>> temporary test. >>>> >>>> Line 302 in case anyone is wondering (thankfully that's the only "48" in >>>> that fike (plus its preceeding comment) ^^') >>> >>> Indeed :-) If it works, it must be made dependent on the target ABI. >> >> It's indeed like that, see section 2.2.2 of >> https://openpowerfoundation.org/wp-content/uploads/2016/03/ABI64BitOpenPOWERv1.1_16July2015_pub4.pdf > > Yes, I checked the docs as well :) I don't know though why it is only 32 > for elf_abi_v2 ... It's because the other ABIs also provide space for a compiler and linker-specific slot: https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#STACK

I've submitted the fix.

Jonas

Reply by email

Unknown author
to Jonas Maebe

Hi Jonas,

fantastic, that looks great. I think now I can just wait until Pierre
Muller's snapshot is updated :=)

Cheers,
Tobias

----

Show quoted text 34 lines
On 26/08/2019 20:56, Jonas Maebe wrote: > On 26/08/2019 20:54, Florian Klaempfl wrote: >> Am 26.08.2019 um 20:52 schrieb Jonas Maebe: >>> On 26/08/2019 14:22, Florian Klämpfl wrote: >>>> Am 26. August 2019 14:08:39 schrieb Sven Barth via fpc-pascal : >>>> >>>>> Florian Klämpfl schrieb am Mo., 26. Aug. 2019, >>>>> 14:01: >>>>> >>>>>> Try to change the 48 in fpc/compiler/powerpc64/cpupara.pas line to 32 as a >>>>>> temporary test. >>>>> >>>>> Line 302 in case anyone is wondering (thankfully that's the only "48" in >>>>> that fike (plus its preceeding comment) ^^') >>>> >>>> Indeed :-) If it works, it must be made dependent on the target ABI. >>> >>> It's indeed like that, see section 2.2.2 of >>> https://openpowerfoundation.org/wp-content/uploads/2016/03/ABI64BitOpenPOWERv1.1_16July2015_pub4.pdf >> >> Yes, I checked the docs as well :) I don't know though why it is only 32 >> for elf_abi_v2 ... > > It's because the other ABIs also provide space for a compiler and > linker-specific slot: > https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#STACK I've submitted the fix. Jonas _______________________________________________ fpc-pascal maillist - https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Kind Regards,
Tobias Giesen

Super Flexible Software GmbH & Co. KG
Buddenstr. 29-31
48143 Münster, Germany
www.superflexible.com
www.tgtools.com

----------------------------------------------------------- Registered at register court Münster as HRA 9716
Liability / general partner: TGTools GmbH
Registered at register court Münster as HRB 17763 Directors: Tobias Giesen and Claudia Giesen

Reply by email

Pierre Muller
to Unknown author

Le 26/08/2019 à 22:46, a écrit :

Hi Jonas, fantastic, that looks great. I think now I can just wait until Pierre Muller's snapshot is updated :=)

As I followed the thread, I made a special issue for you, you should find the new snapshot of ftp site:

$ cat ftp/snapshot/trunk/powerpc64-linux/README-powerpc64-linux This snapshot was generated 2019-08-26 using:
make distclean singlezipinstall SNAPSHOT=1 NOGDB=1 DEBUG=1 NOWPOCYCLE=1 OPT=" -Fl/usr/lib64 -Fl/lib64 -Fd -Fl/usr/lib/gcc/ppc64le-redhat-linux/4.8.5" started using /home/muller/pas/fpc-3.3.1/bin/ppcppc64 ppcppc64 -iVDW output is: 3.3.1 2019/08/26 3.3.1

uname -a of the machine is:
Linux gcc2-power8.osuosl.org 3.10.0-957.10.1.el7.ppc64le #1 SMP Thu Mar 14 11:25:48 GMT 2019 ppc64le ppc64le ppc64le GNU/Linux

"svnversion -c ." output is: 1:1415

"svnversion -c fpcsrc" output is: 1:42841M

Enjoy,

Pierre Muller

PS: note that I do have local modifications that I did not have time to really check... Most are probably not significant, but:

fpcsrc]$ svn diff
Index: rtl/linux/ostypes.inc
=================================================================== --- rtl/linux/ostypes.inc (revision 42841)
+++ rtl/linux/ostypes.inc (working copy)
@@ -170,8 +170,8 @@
FLock = Record
l_type : cshort; { lock type: read/write, etc. } l_whence: cshort; { type of l_start }
- l_start : kernel_off_t; { starting offset }
- l_len : kernel_off_t; { len = 0 means until end of file }
+ l_start : off_t; { starting offset }
+ l_len : off_t; { len = 0 means until end of file } l_pid : pid_t; { lock owner }
{$if defined(cpusparc) or defined(cpusparc64)}

                 __pad   : cshort;

@@ -386,7 +386,7 @@
RLIMIT_LOCKS = 10; { maximum file locks held }

 type
-  rlim_t = cULong;
+  rlim_t = cULongLong;
   PRLimit = ^TRLimit;
   TRLimit = record
     rlim_cur : rlim_t;
Index: rtl/linux/powerpc/stat.inc
===================================================================
--- rtl/linux/powerpc/stat.inc  (revision 42841)
+++ rtl/linux/powerpc/stat.inc  (working copy)
@@ -35,9 +35,9 @@
         st_rdev   : culonglong;
         __pad2_    : cushort;
         st_size   : clonglong;
-        st_blksize: clong;
+        st_blksize: blksize_t;

- st_blocks : clonglong;
+ st_blocks : culonglong;

         st_atime  : clong;
         st_atime_nsec : culong;
         st_mtime  : clong;

Index: rtl/linux/powerpc64/stat.inc
=================================================================== --- rtl/linux/powerpc64/stat.inc (revision 42841) +++ rtl/linux/powerpc64/stat.inc (working copy) @@ -43,5 +43,7 @@

       st_mtime_nsec : cULong;
       st_ctime : cULong;
       st_ctime_nsec : cULong;

- __unused : array[0..2] of cULong;
+ __unused4 : culong;
+ __unused5 : culong;
+ __unused6 : culong;

   end;

Index: rtl/linux/ptypes.inc
=================================================================== --- rtl/linux/ptypes.inc (revision 42841)
+++ rtl/linux/ptypes.inc (working copy)
@@ -206,7 +206,7 @@
bfree, { free blocks in system }
bavail, { Available free blocks to non-root users } files, { File nodes in system }
- ffree : culong; { Free file nodes in system }
+ ffree :{$ifdef cpupowerpc}culonglong{$else}culong{$endif}; { Free file nodes in system } fsid : array[0..1] of cint; { File system ID } namelen, { Maximum name length in system }

     frsize  : cint;

Reply by email

Unknown author
to Pierre Muller

Hi Pierre,

wow that was fast and it works now! Lazarus (trunk) now compiles and
runs without any changes on a POWER9 machine in little endian mode :=)

Very beautiful! I couldn't be happier. Good work everyone!

I'm running it on Ubuntu but I have also installed a few other Linux distributions, all with GUI on this machine. One of them runs with both little and big endian flavors (Void Linux). Will test Lazarus on all of them soon (not sure if big endian will work though, but that's not important). If anybody would like a near silent POWER9 system at home, I can really recommend the new Blackbird mainboard with CPU bundles from Raptor CS. The lower cost 4-core CPU uses so little power you hardly even need a fan for it.

Cheers,
Tobias

----

Show quoted text 103 lines
Le 26/08/2019 à 22:46, a écrit : > Hi Jonas, > > fantastic, that looks great. I think now I can just wait until Pierre > Muller's snapshot is updated :=) As I followed the thread, I made a special issue for you, you should find the new snapshot of ftp site: $ cat ftp/snapshot/trunk/powerpc64-linux/README-powerpc64-linux This snapshot was generated 2019-08-26 using: make distclean singlezipinstall SNAPSHOT=1 NOGDB=1 DEBUG=1 NOWPOCYCLE=1 OPT=" -Fl/usr/lib64 -Fl/lib64 -Fd -Fl/usr/lib/gcc/ppc64le-redhat-linux/4.8.5" started using /home/muller/pas/fpc-3.3.1/bin/ppcppc64 ppcppc64 -iVDW output is: 3.3.1 2019/08/26 3.3.1 uname -a of the machine is: Linux gcc2-power8.osuosl.org 3.10.0-957.10.1.el7.ppc64le #1 SMP Thu Mar 14 11:25:48 GMT 2019 ppc64le ppc64le ppc64le GNU/Linux "svnversion -c ." output is: 1:1415 "svnversion -c fpcsrc" output is: 1:42841M Enjoy, Pierre Muller PS: note that I do have local modifications that I did not have time to really check... Most are probably not significant, but: fpcsrc]$ svn diff Index: rtl/linux/ostypes.inc =================================================================== --- rtl/linux/ostypes.inc (revision 42841) +++ rtl/linux/ostypes.inc (working copy) @@ -170,8 +170,8 @@ FLock = Record l_type : cshort; { lock type: read/write, etc. } l_whence: cshort; { type of l_start } - l_start : kernel_off_t; { starting offset } - l_len : kernel_off_t; { len = 0 means until end of file } + l_start : off_t; { starting offset } + l_len : off_t; { len = 0 means until end of file } l_pid : pid_t; { lock owner } {$if defined(cpusparc) or defined(cpusparc64)} __pad : cshort; @@ -386,7 +386,7 @@ RLIMIT_LOCKS = 10; { maximum file locks held } type - rlim_t = cULong; + rlim_t = cULongLong; PRLimit = ^TRLimit; TRLimit = record rlim_cur : rlim_t; Index: rtl/linux/powerpc/stat.inc =================================================================== --- rtl/linux/powerpc/stat.inc (revision 42841) +++ rtl/linux/powerpc/stat.inc (working copy) @@ -35,9 +35,9 @@ st_rdev : culonglong; __pad2_ : cushort; st_size : clonglong; - st_blksize: clong; + st_blksize: blksize_t; - st_blocks : clonglong; + st_blocks : culonglong; st_atime : clong; st_atime_nsec : culong; st_mtime : clong; Index: rtl/linux/powerpc64/stat.inc =================================================================== --- rtl/linux/powerpc64/stat.inc (revision 42841) +++ rtl/linux/powerpc64/stat.inc (working copy) @@ -43,5 +43,7 @@ st_mtime_nsec : cULong; st_ctime : cULong; st_ctime_nsec : cULong; - __unused : array[0..2] of cULong; + __unused4 : culong; + __unused5 : culong; + __unused6 : culong; end; Index: rtl/linux/ptypes.inc =================================================================== --- rtl/linux/ptypes.inc (revision 42841) +++ rtl/linux/ptypes.inc (working copy) @@ -206,7 +206,7 @@ bfree, { free blocks in system } bavail, { Available free blocks to non-root users } files, { File nodes in system } - ffree : culong; { Free file nodes in system } + ffree :{$ifdef cpupowerpc}culonglong{$else}culong{$endif}; { Free file nodes in system } fsid : array[0..1] of cint; { File system ID } namelen, { Maximum name length in system } frsize : cint; _______________________________________________ fpc-pascal maillist - https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Kind Regards,
Tobias Giesen

Super Flexible Software GmbH & Co. KG
Buddenstr. 29-31
48143 Münster, Germany
www.superflexible.com
www.tgtools.com

----------------------------------------------------------- Registered at register court Münster as HRA 9716
Liability / general partner: TGTools GmbH
Registered at register court Münster as HRB 17763 Directors: Tobias Giesen and Claudia Giesen

Reply by email

Sven Barth
to Unknown author

schrieb am Di., 27. Aug. 2019, 01:38:

Show quoted text 5 lines
If anybody would like a near silent POWER9 system at home, I can really recommend the new Blackbird mainboard with CPU bundles from Raptor CS. The lower cost 4-core CPU uses so little power you hardly even need a fan for it.

If only it wouldn't still be so damn expensive... I'm still a bit miffed that I didn't purchase one of the refurbished Tyan servers with a POWER8 for 250€ a few months ago...

Regards,
Sven

Reply by email

Pierre Muller
to Unknown author: while examining a crash when running Lazarus on ppc64le, I found the following issue in…

Hi,

the testsuite results show no difference,
this probably means that we have no test that checks GCC compatibility for more than 8 parameters...

Tobias, could you send us a small source that allows to check this?

Thanks in advance,

Pierre

Le 26/08/2019 à 00:59, a écrit :

Show quoted text 42 lines
Hello, while examining a crash when running Lazarus on ppc64le, I found the following issue in function calls. Calls to functions with more than eight parameters seem to be implemented differently from how gcc does it in a C program. gcc uses the memory location 96(r1) for the ninth parameter, but FPC uses 112(r1). Therefore, calls to XGetWindowProperty crash. This function has 12 parameters. gcc puts the four last ones into 96(r1), 104(r1), 112(r1), 120(r1), and FPC into 112(r1), 120(r1), 128(r1), 136(r1). What can be done about this? I also noticed that the "file" command in Linux mentioned an additional property of the linked C program I wrote for testing: "for GNU/Linux 3.10.0" The FPC program did not have this tag. The complete "file" outputs are: a.out: ELF 64-bit LSB shared object, 64-bit PowerPC or cisco 7500, version 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.2, BuildID[sha1]=6c5d2b5c7408e74eeda95fbf8d120fe8de0f2f30, for GNU/Linux 3.10.0, with debug_info, not stripped minimalxcrash: ELF 64-bit LSB executable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.2, with debug_info, not stripped Hoping my find will be useful, Best wishes, Tobias Giesen _______________________________________________ fpc-pascal maillist - https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Reply by email

Unknown author
to Pierre Muller

Hello,

yes I will send you a minimal program to call XGetWindowProperty.

Cheers,
Tobias

----

Show quoted text 59 lines
Hi, the testsuite results show no difference, this probably means that we have no test that checks GCC compatibility for more than 8 parameters... Tobias, could you send us a small source that allows to check this? Thanks in advance, Pierre Le 26/08/2019 à 00:59, a écrit : > Hello, > > while examining a crash when running Lazarus on ppc64le, I found the > following issue in function calls. > > Calls to functions with more than eight parameters seem to be > implemented differently from how gcc does it in a C program. > > gcc uses the memory location 96(r1) for the ninth parameter, but FPC > uses 112(r1). > > Therefore, calls to XGetWindowProperty crash. This function has 12 > parameters. gcc puts the four last ones into 96(r1), 104(r1), 112(r1), 120(r1), > and FPC into 112(r1), 120(r1), 128(r1), 136(r1). > > What can be done about this? > > I also noticed that the "file" command in Linux mentioned an additional > property of the linked C program I wrote for testing: > "for GNU/Linux 3.10.0" > > The FPC program did not have this tag. > > The complete "file" outputs are: > > a.out: ELF 64-bit LSB shared object, 64-bit PowerPC or cisco 7500, version > 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.2, > BuildID[sha1]=6c5d2b5c7408e74eeda95fbf8d120fe8de0f2f30, for GNU/Linux > 3.10.0, with debug_info, not stripped > > minimalxcrash: ELF 64-bit LSB executable, 64-bit PowerPC or cisco 7500, > version 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.2, with > debug_info, not stripped > > Hoping my find will be useful, > Best wishes, > Tobias Giesen > > _______________________________________________ > fpc-pascal maillist - > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > _______________________________________________ fpc-pascal maillist - https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Kind Regards,
Tobias Giesen

Super Flexible Software GmbH & Co. KG
Buddenstr. 29-31
48143 Münster, Germany
www.superflexible.com
www.tgtools.com

----------------------------------------------------------- Registered at register court Münster as HRA 9716
Liability / general partner: TGTools GmbH
Registered at register court Münster as HRB 17763 Directors: Tobias Giesen and Claudia Giesen

Reply by email

Florian Klämpfl
to Unknown author

Am 27. August 2019 15:03:46 schrieb

Show quoted text 21 lines
Hello, yes I will send you a minimal program to call XGetWindowProperty. Cheers, Tobias ---- On Tue, 27 Aug 2019 11:35:01 +0200 Pierre Muller wrote: > Hi, > > > the testsuite results show no difference, > this probably means that we have no test that checks > GCC compatibility for more than 8 parameters... > > > Tobias, could you send us a small source that allows to check this?

I think we should extend tcalext with a test for more parameters.

Reply by email

Unknown author
to Pierre Muller: Le 26/08/2019 à 22:46, a écrit : As I followed the thread, I made a special issue for…

Hello,

here's a minimal Pascal program to call XGetWindowProperty: https://www.syncovery.com/minimalxtest.pas

Cheers,
Tobias

----

Show quoted text 103 lines
Le 26/08/2019 à 22:46, a écrit : > Hi Jonas, > > fantastic, that looks great. I think now I can just wait until Pierre > Muller's snapshot is updated :=) As I followed the thread, I made a special issue for you, you should find the new snapshot of ftp site: $ cat ftp/snapshot/trunk/powerpc64-linux/README-powerpc64-linux This snapshot was generated 2019-08-26 using: make distclean singlezipinstall SNAPSHOT=1 NOGDB=1 DEBUG=1 NOWPOCYCLE=1 OPT=" -Fl/usr/lib64 -Fl/lib64 -Fd -Fl/usr/lib/gcc/ppc64le-redhat-linux/4.8.5" started using /home/muller/pas/fpc-3.3.1/bin/ppcppc64 ppcppc64 -iVDW output is: 3.3.1 2019/08/26 3.3.1 uname -a of the machine is: Linux gcc2-power8.osuosl.org 3.10.0-957.10.1.el7.ppc64le #1 SMP Thu Mar 14 11:25:48 GMT 2019 ppc64le ppc64le ppc64le GNU/Linux "svnversion -c ." output is: 1:1415 "svnversion -c fpcsrc" output is: 1:42841M Enjoy, Pierre Muller PS: note that I do have local modifications that I did not have time to really check... Most are probably not significant, but: fpcsrc]$ svn diff Index: rtl/linux/ostypes.inc =================================================================== --- rtl/linux/ostypes.inc (revision 42841) +++ rtl/linux/ostypes.inc (working copy) @@ -170,8 +170,8 @@ FLock = Record l_type : cshort; { lock type: read/write, etc. } l_whence: cshort; { type of l_start } - l_start : kernel_off_t; { starting offset } - l_len : kernel_off_t; { len = 0 means until end of file } + l_start : off_t; { starting offset } + l_len : off_t; { len = 0 means until end of file } l_pid : pid_t; { lock owner } {$if defined(cpusparc) or defined(cpusparc64)} __pad : cshort; @@ -386,7 +386,7 @@ RLIMIT_LOCKS = 10; { maximum file locks held } type - rlim_t = cULong; + rlim_t = cULongLong; PRLimit = ^TRLimit; TRLimit = record rlim_cur : rlim_t; Index: rtl/linux/powerpc/stat.inc =================================================================== --- rtl/linux/powerpc/stat.inc (revision 42841) +++ rtl/linux/powerpc/stat.inc (working copy) @@ -35,9 +35,9 @@ st_rdev : culonglong; __pad2_ : cushort; st_size : clonglong; - st_blksize: clong; + st_blksize: blksize_t; - st_blocks : clonglong; + st_blocks : culonglong; st_atime : clong; st_atime_nsec : culong; st_mtime : clong; Index: rtl/linux/powerpc64/stat.inc =================================================================== --- rtl/linux/powerpc64/stat.inc (revision 42841) +++ rtl/linux/powerpc64/stat.inc (working copy) @@ -43,5 +43,7 @@ st_mtime_nsec : cULong; st_ctime : cULong; st_ctime_nsec : cULong; - __unused : array[0..2] of cULong; + __unused4 : culong; + __unused5 : culong; + __unused6 : culong; end; Index: rtl/linux/ptypes.inc =================================================================== --- rtl/linux/ptypes.inc (revision 42841) +++ rtl/linux/ptypes.inc (working copy) @@ -206,7 +206,7 @@ bfree, { free blocks in system } bavail, { Available free blocks to non-root users } files, { File nodes in system } - ffree : culong; { Free file nodes in system } + ffree :{$ifdef cpupowerpc}culonglong{$else}culong{$endif}; { Free file nodes in system } fsid : array[0..1] of cint; { File system ID } namelen, { Maximum name length in system } frsize : cint; _______________________________________________ fpc-pascal maillist - https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Kind Regards,
Tobias Giesen

Super Flexible Software GmbH & Co. KG
Buddenstr. 29-31
48143 Münster, Germany
www.superflexible.com
www.tgtools.com

----------------------------------------------------------- Registered at register court Münster as HRA 9716
Liability / general partner: TGTools GmbH
Registered at register court Münster as HRB 17763 Directors: Tobias Giesen and Claudia Giesen

Reply by email