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
