Re: [Pkg-pascal-devel] Debugging FPC build issue on m68k

2020-08-20 Thread Karoly Balogh (Charlie/SGR)
Hi,

On Thu, 20 Aug 2020, John Paul Adrian Glaubitz wrote:

> >>> If this also crashes, then I have to dig deeper to identify the problem,
> >>> because 3.2.x will be with us for a while, and I'd like it to be built for
> >>> Debian-m68k.
> >>
> >> It still fails with:
> >>
> >> numlib/units/m68k-linux/spe.s: Assembler messages:
> >> numlib/units/m68k-linux/spe.s:1751: Error: cannot create floating-point 
> >> number
> >> spe.pas(1793) Error: Error while assembling exitcode 1
> >> spe.pas(1793) Fatal: There were 2 errors compiling module, stopping
> >> Fatal: Compilation aborted
> >
> > Can you send me that spe.s file which fails to compile?
>
> See attached.

Ok, so the generated assembly is indeed wrong, but it's different to the
cross-compiled assembly. What happens is in the optimizer the compiler
tries to determine the lowest possible precision of a floating point
constant, and this seems to go badly wrong in this case, and the compiler
figures it can do a single precision floating point load for a double
precision inline constant. And the assembler complains about that.

However, I verified on real hardware (68060), I cannot reproduce this at
least with the 3.2.0 Amiga native compiler, neither for native Amiga code,
nor when crossbuilding for Linux. Then the generated assembly is always
correct. I also verified if the native compiler contains the correct code
sequence (by disassembling its binary) for that opimization, and the
answer is yes.

I really need to put my real hardware Linux-m68k setup together again, to
be 100% sure this is not an FPC issue, but at this point I think it isn't.

What is the build host? QEMU? If yes, which version? I tested a slightly
older QEMU (3.1, as bundled with Raspbian), and its floating point support
seems quite badly broken. Even trivial code which uses the FPU seems to
fail. Like, printing the value of "Pi" seems to show '4.0' ... :) Like
it's permanently stuck in round up mode, but fiddling with FPCR values
don't seem to change anything. Same code works on real hardware and in
UAE.

BTW, FPU problems didn't occur in Free Pascal 3.0.4 because that could not
use FPU at all, so this is not a regression. FPU support was new in 3.2.0
for m68k. You can switch to software floating point support by passing
OPT="-CfSOFT" argument to the Makefile (this was the default in 3.0.4 for
m68k). But this shouldn't be the default in a 3.2.0 Debian package, but
maybe worth a shot for a test.

Cheers,
--
Charlie



Re: [Pkg-pascal-devel] Debugging FPC build issue on m68k

2020-08-20 Thread Karoly Balogh (Charlie/SGR)
Hi,

On Thu, 20 Aug 2020, John Paul Adrian Glaubitz wrote:

> > I cross-built a recent 3.2.1 compiler from our fixes_3_2 branch (this will
> > be released as 3.2.2, eventually), I uploaded it here:
> >
> > https://coderetro.net/temp/linux-m68k/
> >
> > Can you try bootstrapping with this compiler binary? At least from FPC's
> > perspective, you shouldn't need anything else, to initiate a cross build
> > than a bootstrap compiler binary, and GNU binutils and make. Not sure if
> > Debian needs anything else.
> >
> > If this also crashes, then I have to dig deeper to identify the problem,
> > because 3.2.x will be with us for a while, and I'd like it to be built for
> > Debian-m68k.
>
> It still fails with:
>
> numlib/units/m68k-linux/spe.s: Assembler messages:
> numlib/units/m68k-linux/spe.s:1751: Error: cannot create floating-point number
> spe.pas(1793) Error: Error while assembling exitcode 1
> spe.pas(1793) Fatal: There were 2 errors compiling module, stopping
> Fatal: Compilation aborted

Can you send me that spe.s file which fails to compile? Also, which
version of binutils is used? As this error comes from binutils (as), and
not FPC itself, of course it could be that the generated assembly is
broken at that line. I have a local build of (cross-)binutils 2.27, which
I was using for testing. Maybe I should try with a newer one.

> I used your binary and the source tarball for FPC 3.2.0.

I do have a build of that unit locally, and it builds without an issue,
although admittedly, it's a cross build.

Charlie



Re: [Pkg-pascal-devel] Debugging FPC build issue on m68k

2020-08-20 Thread John Paul Adrian Glaubitz
On 8/20/20 12:20 PM, Karoly Balogh (Charlie/SGR) wrote:
> I cross-built a recent 3.2.1 compiler from our fixes_3_2 branch (this will
> be released as 3.2.2, eventually), I uploaded it here:
> 
> https://coderetro.net/temp/linux-m68k/
> 
> Can you try bootstrapping with this compiler binary? At least from FPC's
> perspective, you shouldn't need anything else, to initiate a cross build
> than a bootstrap compiler binary, and GNU binutils and make. Not sure if
> Debian needs anything else.
> 
> If this also crashes, then I have to dig deeper to identify the problem,
> because 3.2.x will be with us for a while, and I'd like it to be built for
> Debian-m68k.

It still fails with:

numlib/units/m68k-linux/spe.s: Assembler messages:
numlib/units/m68k-linux/spe.s:1751: Error: cannot create floating-point number
spe.pas(1793) Error: Error while assembling exitcode 1
spe.pas(1793) Fatal: There were 2 errors compiling module, stopping
Fatal: Compilation aborted

The installer encountered the following error:
Compilation of "BuildUnit_numlib.pp" failed
make[2]: *** [Makefile:1729: smart] Error 1
make[2]: Leaving directory '/root/src/fpc-3.2.0/packages'
make[1]: *** [Makefile:2681: packages_smart] Error 2
make[1]: Leaving directory '/root/src/fpc-3.2.0'
make: *** [Makefile:2836: build-stamp.m68k-linux] Error 2

I used your binary and the source tarball for FPC 3.2.0.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Re: [Pkg-pascal-devel] Debugging FPC build issue on m68k

2020-08-20 Thread Karoly Balogh (Charlie/SGR)
Hi,

On Thu, 20 Aug 2020, Abou Al Montacir wrote:

>> It turned out, our SVN trunk was broken for Linux-m68k, so I fixed that
>>  meanwhile, but FPC 3.2.0 was forked earlier to that breakage, so if
>> there's an issue it must be different. I'll get there, meanwhile but of
>> course any input is welcome.
>
> I looked deeper in the issue and it seems that it may be a bug in the
> initial compiler /usr/bin/ppc68k which is used to bootstrap the cycle.
> This compiler is of version 3.0.4+dfsg-23.

Thanks for looking into this!

Yeah, 3.0.4 is a very early version for m68k (after the m68k backend got
revived), and the 3.0.4 was maybe the first ever version which really
worked on Linux-m68k. So I was actually kinda surprised it even worked to
that level, so it could be included in Debian... :) I would avoid fighting
with that if possible.

> So a possible way to overcome this is to perform a binary upload to
> m68k. However I was not able to generate packages by cross compilation.

I cross-built a recent 3.2.1 compiler from our fixes_3_2 branch (this will
be released as 3.2.2, eventually), I uploaded it here:

https://coderetro.net/temp/linux-m68k/

Can you try bootstrapping with this compiler binary? At least from FPC's
perspective, you shouldn't need anything else, to initiate a cross build
than a bootstrap compiler binary, and GNU binutils and make. Not sure if
Debian needs anything else.

If this also crashes, then I have to dig deeper to identify the problem,
because 3.2.x will be with us for a while, and I'd like it to be built for
Debian-m68k.

Cheers,
--
Charlie

Re: [Pkg-pascal-devel] Debugging FPC build issue on m68k

2020-08-20 Thread Abou Al Montacir
Hi Charlie,

On Wed, 2020-08-12 at 11:38 +0200, Karoly Balogh (Charlie/SGR) wrote:
> Sorry for the delayed response, yes, we in upstream are willing to fix
> theissue, although we run regular tests with QEMU, and those are lookinggood.
> So not sure what could cause that build problem, but we're alsomostly doing
> cross-builds with m68k, not native builds.
> I know I promised to look into this, but never really had time in the lastfew
> weeks, sorry about it. It turned out, our SVN trunk was broken forLinux-m68k,
> so I fixed that meanwhile, but FPC 3.2.0 was forked earlier tothat breakage,
> so if there's an issue it must be different. I'll getthere, meanwhile but of
> course any input is welcome.
I looked deeper in the issue and it seems that it may be a bug in the initial
compiler /usr/bin/ppc68k which is used to bootstrap the cycle.
This compiler is of version 3.0.4+dfsg-23.

So a possible way to overcome this is to perform a binary upload to m68k.
However I was not able to generate packages by cross compilation.
-- 
Cheers,
Abou Al Montacir


signature.asc
Description: This is a digitally signed message part


Re: Debugging FPC build issue on m68k

2020-08-12 Thread Karoly Balogh (Charlie/SGR)
Hi,

On Tue, 4 Aug 2020, John Paul Adrian Glaubitz wrote:

> On 8/4/20 5:33 PM, Abou Al Montacir wrote:

> > I started looking at the m68k build issue, but the buildd logs are not
> > enough to understand what happens. I tried to find a m68k machine on
> > porter boxes but failed to find any. Also building a qemu image does
> > not seem as straight forward as I expected, so I'd like to know if
> > anybody can help providing access to a machine or a qemu image that I
> > can download. Of course, any help to debug this issue is more than
> > welcome.
>
> I have already reported this issue upstream [1], but so far I have not
> received any feedback. Charlie (CC'ed) from upstream who is mainly
> responsible for the m68k backend as far as I know said he would look
> into it.
>
> If you want to set up a Debian/m68k VM yourself, please have a look at [2].

Sorry for the delayed response, yes, we in upstream are willing to fix the
issue, although we run regular tests with QEMU, and those are looking
good. So not sure what could cause that build problem, but we're also
mostly doing cross-builds with m68k, not native builds.

I know I promised to look into this, but never really had time in the last
few weeks, sorry about it. It turned out, our SVN trunk was broken for
Linux-m68k, so I fixed that meanwhile, but FPC 3.2.0 was forked earlier to
that breakage, so if there's an issue it must be different. I'll get
there, meanwhile but of course any input is welcome.

Charlie



Re: [Pkg-pascal-devel] Debugging FPC build issue on m68k

2020-08-04 Thread Abou Al Montacir
Hi Adrian,
On Tue, 2020-08-04 at 22:26 +0200, John Paul Adrian Glaubitz wrote:
> Hi Abou!
> On 8/4/20 5:33 PM, Abou Al Montacir wrote:
> > I started looking at the m68k build issue, but the buildd logs are not
> > enough tounderstand what happens.I tried to find a m68k machine on porter
> > boxes but failed to find any.Also building a qemu image does not seem as
> > straight forward as I expected, soI'd like to know if anybody can help
> > providing access to a machine or a qemuimage that I can download.Of course,
> > any help to debug this issue is more than welcome.
> 
> I have already reported this issue upstream [1], but so far I have not
> receivedany feedback. Charlie (CC'ed) from upstream who is mainly responsible
> for them68k backend as far as I know said he would look into it.
It looks that Pierre already answered there and is waiting for feedback.
> If you want to set up a Debian/m68k VM yourself, please have a look at [2].
That looks too complicated for me.
I don't feel having the energy to build my qemu and install my image.

I've got a qcow2 image from Laurent (many thanks)
I'm going to have a trial with qemu-system-misc (1:3.1+dfsg-8+deb10u7)
-- 
Cheers,
Abou Al Montacir




signature.asc
Description: This is a digitally signed message part


Re: Debugging FPC build issue on m68k

2020-08-04 Thread John Paul Adrian Glaubitz
Hi Abou!

On 8/4/20 5:33 PM, Abou Al Montacir wrote:
> I started looking at the m68k build issue, but the buildd logs are not enough 
> to
> understand what happens.
> I tried to find a m68k machine on porter boxes but failed to find any.
> Also building a qemu image does not seem as straight forward as I expected, so
> I'd like to know if anybody can help providing access to a machine or a qemu
> image that I can download.
> Of course, any help to debug this issue is more than welcome.

I have already reported this issue upstream [1], but so far I have not received
any feedback. Charlie (CC'ed) from upstream who is mainly responsible for the
m68k backend as far as I know said he would look into it.

If you want to set up a Debian/m68k VM yourself, please have a look at [2].

Thanks,
Adrian

> [1] https://bugs.freepascal.org/view.php?id=37250
> [2] https://wiki.debian.org/M68k/QemuSystemM68k

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Re: Debugging FPC build issue on m68k

2020-08-04 Thread Carsten Strotmann

Hello Abou Al Montacir,

Abou Al Montacir  writes:


Dear Teams,

I started looking at the m68k build issue, but the buildd logs 
are not enough to

understand what happens.
I tried to find a m68k machine on porter boxes but failed to 
find any.
Also building a qemu image does not seem as straight forward as 
I expected, so
I'd like to know if anybody can help providing access to a 
machine or a qemu

image that I can download.
Of course, any help to debug this issue is more than welcome.


I can possibly setup a machine in the Internet with qemu emulation 
for

you, and I can also send you a download link for my Debian m68k
directory and instructions on how to setup a emulated system from 
the

image download.

I can probably have that ready by Thursday this week. Let me know 
if you
would like to try that, or if you got access to a machine 
somewhere

else.

Greetings

Carsten



Debugging FPC build issue on m68k

2020-08-04 Thread Abou Al Montacir
Dear Teams,

I started looking at the m68k build issue, but the buildd logs are not enough to
understand what happens.
I tried to find a m68k machine on porter boxes but failed to find any.
Also building a qemu image does not seem as straight forward as I expected, so
I'd like to know if anybody can help providing access to a machine or a qemu
image that I can download.
Of course, any help to debug this issue is more than welcome.
-- 
Cheers,
Abou Al Montacir



signature.asc
Description: This is a digitally signed message part