ppc64le ABI problem

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

ppc64le ABI problem

tobiasgiesen
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  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ppc64le ABI problem

Florian Klämpfl
Am 26. August 2019 00:59:16 schrieb [hidden email]:

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

>
>
> 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  -  [hidden email]
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal




_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ppc64le ABI problem

Free Pascal - General mailing list
Florian Klämpfl <[hidden email]> schrieb am Mo., 26. Aug. 2019, 14:01:
Am 26. August 2019 00:59:16 schrieb [hidden email]:

> 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 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ppc64le ABI problem

Florian Klämpfl
Am 26. August 2019 14:08:39 schrieb Sven Barth via fpc-pascal <[hidden email]>:

> Florian Klämpfl <[hidden email]> schrieb am Mo., 26. Aug. 2019,
> 14:01:
>
>> Am 26. August 2019 00:59:16 schrieb [hidden email]:
>>
>>> 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  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ppc64le ABI problem

tobiasgiesen
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

----

On Mon, 26 Aug 2019 14:22:01 +0200
Florian Klämpfl <[hidden email]> wrote:

> Am 26. August 2019 14:08:39 schrieb Sven Barth via fpc-pascal <[hidden email]>:
>
> > Florian Klämpfl <[hidden email]> schrieb am Mo., 26. Aug. 2019,
> > 14:01:
> >
> >> Am 26. August 2019 00:59:16 schrieb [hidden email]:
> >>
> >>> 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  -  [hidden email]
> 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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ppc64le ABI problem

tobiasgiesen
In reply to this post by Florian Klämpfl
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


_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ppc64le ABI problem

Free Pascal - General mailing list
<[hidden email]> schrieb am Mo., 26. Aug. 2019, 19:53:
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 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ppc64le ABI problem

Jonas Maebe-3
In reply to this post by Florian Klämpfl
On 26/08/2019 14:22, Florian Klämpfl wrote:

> Am 26. August 2019 14:08:39 schrieb Sven Barth via fpc-pascal <[hidden email]>:
>
>> Florian Klämpfl <[hidden email]> 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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ppc64le ABI problem

Florian Klämpfl
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 <[hidden email]>:
>>
>>> Florian Klämpfl <[hidden email]> 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 ...

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ppc64le ABI problem

Jonas Maebe-3
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 <[hidden email]>:
>>>
>>>> Florian Klämpfl <[hidden email]> 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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ppc64le ABI problem

Jonas Maebe-3
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 <[hidden email]>:
>>>>
>>>>> Florian Klämpfl <[hidden email]> 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  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ppc64le ABI problem

tobiasgiesen
Hi Jonas,

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

Cheers,
Tobias

----

On Mon, 26 Aug 2019 21:42:37 +0200
Jonas Maebe <[hidden email]> wrote:

> 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 <[hidden email]>:
> >>>>
> >>>>> Florian Klämpfl <[hidden email]> 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  -  [hidden email]
> 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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ppc64le ABI problem

Pierre Muller


Le 26/08/2019 à 22:46, [hidden email] 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:

[muller@gcc2-power8 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  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ppc64le ABI problem

tobiasgiesen
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


----

On Mon, 26 Aug 2019 23:22:01 +0200
Pierre Muller <[hidden email]> wrote:

>
>
> Le 26/08/2019 à 22:46, [hidden email] 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:
>
> [muller@gcc2-power8 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  -  [hidden email]
> 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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ppc64le ABI problem

Free Pascal - General mailing list
<[hidden email]> schrieb am Di., 27. Aug. 2019, 01:38:
 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 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ppc64le ABI problem

Pierre Muller
In reply to this post by tobiasgiesen
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, [hidden email] 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  -  [hidden email]
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ppc64le ABI problem

tobiasgiesen
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 <[hidden email]> 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?
>
> Thanks in advance,
>
> Pierre
>
>
> Le 26/08/2019 à 00:59, [hidden email] 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  -  [hidden email]
> > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
> >
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> 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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ppc64le ABI problem

Florian Klämpfl
Am 27. August 2019 15:03:46 schrieb [hidden email]:

> 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 <[hidden email]> 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.


_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ppc64le ABI problem

tobiasgiesen
In reply to this post by Pierre Muller
Hello,

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

Cheers,
Tobias

----

On Mon, 26 Aug 2019 23:22:01 +0200
Pierre Muller <[hidden email]> wrote:

>
>
> Le 26/08/2019 à 22:46, [hidden email] 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:
>
> [muller@gcc2-power8 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  -  [hidden email]
> 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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal