Hi,
Thanks for looking at this. The focus before the release of 5.8 was on
the X86 and in particular the 32/64 version. The interpreted version
wasn't really tested to the same extent. Since then I've fixed a couple
of bugs that affected the interpreted version when I tested it on ARM
and Mips development boards. Once of these caused a segfault and the
other affected some of the Real32.real arithmetic. These fixed have
been pushed to git master and I'm planning to add them to the fixes-5.8
branch.
It would be very helpful if you could rerun your tests with master so I
know whether the bugs you've encountered have actually been fixed.
The test for .note.GNU-stack is only relevant on the X86 so configure
should probably be changed so that this test is omitted in the
interpreted version.
Regards,
David
On 24/03/2019 23:37, Jerry James wrote:
This weekend, I attempted to build polyml 5.8 for Fedora (Rawhide for
now, hopefully Fedora 30 later). I encountered issues with the 32-bit
ARM build and the s390x build.
On s390x, immediately after the C++ code is compiled, polyimport is
executed for the first time:
./polyimport polytemp.txt -I . < ./exportPoly.sml
/bin/sh: line 1: 33283 Segmentation fault (core dumped)
./polyimport polytemp.txt -I . < ./exportPoly.sml
GDB says:
(gdb) bt
#0 0x000003fffde56ce6 in PolyObject::Get (this=0x8017c8fcff030000, i=0)
at globals.h:311
#1 0x000003fffdebbfce in IntTaskData::SwitchToPoly (this=0x10336d0)
at interpret.cpp:761
#2 0x000003fffdec2830 in IntTaskData::EnterPolyCode (this=0x10336d0)
at interpret.cpp:2261
#3 0x000003fffde92eea in NewThreadFunction (parameter=0x10336d0)
at processes.cpp:1307
#4 0x000003fffdb89da6 in start_thread () from /usr/lib64/libpthread.so.0
#5 0x000003fffdd01b06 in thread_start () from /usr/lib64/libc.so.6
Notice the "this" parameter in frame 0. That is an invalid address
... unless one reverses the bytes to get 0x000003fffcc81780, which is
a valid address. The code that produces the argument to indirect_0
has apparently done so in little endian byte order. If you can tell
me where to look, I can help debug this further. The presence or
absence of --enable-compact32bit makes no difference; the segfault
happens either way.
On 32-bit ARM, the build succeeds, but one test fails:
Tests/Succeed/Test174.ML. The first two failures are on lines 34 and
35:
check(Real32.fromLarge IEEEReal.TO_ZERO pm < p32);
check(Real32.fromLarge IEEEReal.TO_ZERO mp > m32);
Entering those values by hand at the polyml command prompt I get:
Real32.fromLarge IEEEReal.TO_ZERO pm;
val it = 3.141592741: Real32.real
p32;
val it = 3.141592741: ?.Math.real
Real32.fromLarge IEEEReal.TO_ZERO mp;
val it = ~3.141592741: Real32.real
Then the tests at lines 40 and 42 fail:
check(Real32.fromLarge IEEEReal.TO_POSINF pp > p32);
check(Real32.fromLarge IEEEReal.TO_POSINF mp > m32);
Real32.fromLarge IEEEReal.TO_POSINF pp;
val it = 3.141592741: Real32.real
Real32.fromLarge IEEEReal.TO_POSINF mp;
val it = ~3.141592741: Real32.real
Likewise, the tests at lines 48 and 50 fail:
check(Real32.fromLarge IEEEReal.TO_NEGINF pm < p32);
check(Real32.fromLarge IEEEReal.TO_NEGINF mm < m32);
Real32.fromLarge IEEEReal.TO_NEGINF pm;
val it = 3.141592741: Real32.real
Real32.fromLarge IEEEReal.TO_NEGINF mm;
val it = ~3.141592741: Real32.real
The output of configure on ARM seems okay, although I will note an
entirely different problem:
configure:17740: checking whether as supports .note.GNU-stack
configure:17753: armv7hl-redhat-linux-gnueabi-gcc -c -O2 -g -pipe
-Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
-march=armv7-a -mfpu=vfpv3-d16 -mtune=generic-armv7-a
-mabi=aapcs-linux -mfloat-abi=hard -fno-strict-aliasing -D_GNU_SOURCE
conftest.c >&5
{standard input}: Assembler messages:
{standard input}:552: Error: junk at end of line, first unrecognized
character is `,'
configure:17753: $? = 1
configure: failed program was:
| /* confdefs.h */
[ skip lots of #defines that don't matter]
| /* end confdefs.h. */
| __asm__(".section .note.GNU-stack,\"\",@progbits");
| int
| main ()
| {
|
| ;
| return 0;
| }
Taking a clue from the output of gcc -S conftest.c -fverbose-asm after
removing the __asm__ line above, I changed @progbits to %progbits, and
then the test worked.
Advice on how to proceed w.r.t the floating point issues with the ARM
build is much appreciated. Regards,
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
