Hi David, Is this on Debian Jessie (current stable)? I've been doing all my work on Sid (new package versions are always built on unstable unless they are backports), which has GCC 5 (I believe it built fine under GCC 4.x, though I never ran the test suite); I had forgotten to mention this important fact, sorry about that! As this is for the Debian package, it's using their default compiler flags, although I think it breaks with either. Thanks for taking time to look at this though; I will continue to experiment as well.
Regards, James > On 18 Jan 2016, at 18:54, David Matthews <[email protected]> > wrote: > > James, > I've managed to set up a big-endian mips debian virtual machine using qemu > inside a virtual debian machine in virtualbox on Windows. Despite all the > layers of virtualisation it works and more importantly Poly/ML actually > builds successfully. It does crash with some larger examples, such as > Tests/Succeed/Test133.ML, and I've seen some other crashes in the > garbage-collector. I suspect that there is a problem with endian-ness > somewhere but it may be possible to narrow this down with gdb. > > Regards, > David > >> On 16/01/2016 17:01, James Clarke wrote: >> Hi David, >> I just tried building on mipsel, and that compiles and passes the test suite >> with the same compiler flags. Endianness is looking like a strong candidate, >> given that the only architectures it fails on are big-endian, although >> compiler optimisations are “responsible”. I shall see if a very old version >> works on big-endian mips; if so, I will try and do a git bisect, otherwise >> it might have to be some painful debugging. >> >> Regards, >> James >> >>> On 15 Jan 2016, at 11:59, James Clarke <[email protected]> wrote: >>> >>> They are all big-endian. I haven't tried mipsel; that could help narrow it >>> down. One thing making me not so sure it's an endianness issue is that you >>> support 32-bit PowerPC, and that runs properly. Also the mips builds are >>> broken by GCC's optimisations; adding -fno-omit-frame-pointer made it work >>> for some reason, if I remember correctly. >>> >>> James >>> >>>> On 15 Jan 2016, at 11:29, David Matthews <[email protected]> >>>> wrote: >>>> >>>> I wish I could help but there's not much I can suggest. The only idea >>>> that occurs to me is that there is some endian-ness issue that has crept >>>> in. Are these little-endian or big-endian? In theory the interpreter >>>> should work on both big-endian and little-endian but I've only tested the >>>> most recent version on X86. Have a look at an earlier version of Poly/ML >>>> and see if you have any more success with that. >>>> >>>> David >>>> >>>>> On 12/01/2016 14:52, James Clarke wrote: >>>>> Hi, >>>>> I’ve been trying to port Poly/ML to mips and IBM’s S/390 (the 64-bit >>>>> version, often referred to as s390x). For both, I tried just adding an >>>>> extra case in configure.ac, along with corresponding HOSTARCHITECTURE >>>>> macros and cases in libpolyml/elfexport.cpp. However, these all seem to >>>>> segfault when polyimport is run when building (both with 5.5.2 and git >>>>> commit ee26375, "Merge branch ‘PICTest’"). I can’t seem to get a >>>>> meaningful stack trace out of the mips segfault, but it crashes just >>>>> after “Use: basis/Socket.sml” is printed. However, on s390x, it crashes >>>>> before anything is printed, and valgrind gave me the following (with no >>>>> errors before this point) when running ee26375’s polyimport: >>>>> >>>>> ==16138== Thread 3: >>>>> ==16138== Invalid read of size 8 >>>>> ==16138== at 0x489EA50: Offset (globals.h:315) >>>>> ==16138== by 0x489EA50: GetConstSegmentForCode (globals.h:344) >>>>> ==16138== by 0x489EA50: GetConstSegmentForCode (globals.h:350) >>>>> ==16138== by 0x489EA50: ConstPtrForCode (globals.h:355) >>>>> ==16138== by 0x489EA50: buildStackList(TaskData*, PolyWord*, >>>>> PolyWord*) (run_time.cpp:413) >>>>> ==16138== by 0x489EC87: exceptionToTraceException(TaskData*, >>>>> SaveVecEntry*) (run_time.cpp:471) >>>>> ==16138== by 0x48AC9ED: IntTaskData::SwitchToPoly() (interpret.cpp:877) >>>>> ==16138== by 0x48ACC33: IntTaskData::EnterPolyCode() >>>>> (interpret.cpp:1428) >>>>> ==16138== by 0x489324D: NewThreadFunction(void*) (processes.cpp:1128) >>>>> ==16138== by 0x48E591D: start_thread (pthread_create.c:335) >>>>> ==16138== by 0x4C8CEA9: ??? (in /lib/s390x-linux-gnu/libc-2.21.so) >>>>> ==16138== Address 0xe000000005ab5b38 is not stack'd, malloc'd or >>>>> (recently) free'd >>>>> ==16138== >>>>> ==16138== >>>>> ==16138== Process terminating with default action of signal 11 (SIGSEGV) >>>>> ==16138== Access not within mapped region at address 0xE000000005AB5000 >>>>> ==16138== at 0x489EA50: Offset (globals.h:315) >>>>> ==16138== by 0x489EA50: GetConstSegmentForCode (globals.h:344) >>>>> ==16138== by 0x489EA50: GetConstSegmentForCode (globals.h:350) >>>>> ==16138== by 0x489EA50: ConstPtrForCode (globals.h:355) >>>>> ==16138== by 0x489EA50: buildStackList(TaskData*, PolyWord*, >>>>> PolyWord*) (run_time.cpp:413) >>>>> ==16138== by 0x489EC87: exceptionToTraceException(TaskData*, >>>>> SaveVecEntry*) (run_time.cpp:471) >>>>> ==16138== by 0x48AC9ED: IntTaskData::SwitchToPoly() (interpret.cpp:877) >>>>> ==16138== by 0x48ACC33: IntTaskData::EnterPolyCode() >>>>> (interpret.cpp:1428) >>>>> ==16138== by 0x489324D: NewThreadFunction(void*) (processes.cpp:1128) >>>>> ==16138== by 0x48E591D: start_thread (pthread_create.c:335) >>>>> ==16138== by 0x4C8CEA9: ??? (in /lib/s390x-linux-gnu/libc-2.21.so) >>>>> ==16138== If you believe this happened as a result of a stack >>>>> ==16138== overflow in your program's main thread (unlikely but >>>>> ==16138== possible), you can try to increase the size of the >>>>> ==16138== main thread stack using the --main-stacksize= flag. >>>>> ==16138== The main thread stack size used in this run was 8388608. >>>>> >>>>> (the ??? for libc is because valgrind does not yet understand compressed >>>>> debug info; I removed a whole load of warnings to that effect) >>>>> >>>>> Have you ever come across anything like this? Do you have any thoughts >>>>> for where to start with hunting this down? >>>>> >>>>> Regards, >>>>> James Clarke >>>>> >>>>> _______________________________________________ >>>>> polyml mailing list >>>>> [email protected] >>>>> http://lists.inf.ed.ac.uk/mailman/listinfo/polyml >>>>> >>>> _______________________________________________ >>>> polyml mailing list >>>> [email protected] >>>> http://lists.inf.ed.ac.uk/mailman/listinfo/polyml >> >> >> >> _______________________________________________ >> polyml mailing list >> [email protected] >> http://lists.inf.ed.ac.uk/mailman/listinfo/polyml >> > _______________________________________________ > polyml mailing list > [email protected] > http://lists.inf.ed.ac.uk/mailman/listinfo/polyml _______________________________________________ polyml mailing list [email protected] http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
