Re: [fpc-pascal] ppc64le ABI problem
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 wrote:
>
>
> Le 26/08/2019 à 22:46, tobiasgie...@gmail.com 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 - fpc-pascal@lists.freepascal.org
> 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 - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
Am 27. August 2019 15:03:46 schrieb tobiasgie...@gmail.com: > 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
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? > > Thanks in advance, > > Pierre > > > Le 26/08/2019 à 00:59, tobiasgie...@gmail.com 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 - fpc-pascal@lists.freepascal.org > > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > 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 - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
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, tobiasgie...@gmail.com 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 - fpc-pascal@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
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 - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
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 wrote:
>
>
> Le 26/08/2019 à 22:46, tobiasgie...@gmail.com 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 - fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Kind Regards,
Tobias Giesen
Super Flexible Software GmbH & Co. KG
Buddenstr. 29-31
Re: [fpc-pascal] ppc64le ABI problem
Le 26/08/2019 à 22:46, tobiasgie...@gmail.com 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 - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
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 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 > : > > > 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 - fpc-pascal@lists.freepascal.org > 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 - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
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 - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
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 Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
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 ... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
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 Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
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 - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
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 - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
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 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: > > > >> Am 26. August 2019 00:59:16 schrieb tobiasgie...@gmail.com: > >> > >>> 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 - fpc-pascal@lists.freepascal.org > 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 - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
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 tobiasgie...@gmail.com: >> >>> 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 - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
Florian Klämpfl schrieb am Mo., 26. Aug. 2019, 14:01: > Am 26. August 2019 00:59:16 schrieb tobiasgie...@gmail.com: > > > 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 - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
Am 26. August 2019 00:59:16 schrieb tobiasgie...@gmail.com: > 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 - fpc-pascal@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] ppc64le ABI problem
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 - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
