Greetings! Andreas Barth <[email protected]> writes:
> Hi, > > I need to admit: ugh. I'm by far not an porter enough for this, but > please send your results to [email protected]. I'm happy to provide > hardware data (mayer and rem are swarm machines, phrixos is loongson > 2f), and let other people access the machines here if helpful. I > probably could also arrange access to an swarm-class mipsel machine. > It appears that access to a 'swarm-class' machine is the only way forward now. Can this be arranged? Take care, David Daney <[email protected]> writes: > On 08/08/2010 08:42 PM, Camm Maguire wrote: >> Greetings! Forwarded from a conversation between Andreas and me. >> Suggestions most welcome. >> >> Take care, >> >> ============================================================================= >> Hi, >> >> I need to admit: ugh. I'm by far not an porter enough for this, but >> please send your results to [email protected]. I'm happy to provide >> hardware data (mayer and rem are swarm machines, phrixos is loongson >> 2f), and let other people access the machines here if helpful. I >> probably could also arrange access to an swarm-class mipsel machine. >> >> >> >> Andi >> >> >> >> * Camm Maguire ([email protected]) [100730 17:55]: >>> Greetings! >>> >>> Regarding >>> >>> >>> https://buildd.debian.org/fetch.cgi?pkg=axiom&arch=mipsel&ver=20100701-1&stamp=1280388149&file=log&as=raw >>> >>> The gcl was built on phrixos, and I just successfully compiled axiom >>> the package there using this same gcl binary package. There seems to >>> be some skew between the mipsel machines, and I think it involves >>> sigaction. >>> >>> You still have the bad -60 binary built on some other mipsel machine >>> installed on phrixos. This segfaults on startup, in the following >>> routine: >>> >>> void >>> memory_protect(int on) { >>> >>> unsigned long i,beg,end= ((unsigned long)(((unsigned long)(((char >>> *)(core_end))-0x0)>>14))); >>> int writable=1; >>> extern void install_segmentation_catcher(void); >>> >>> if (first_protectable_page==0) { >>> for (i=page_multiple; i< maxpage ; i++) >>> if (type_map[i]!=t_other) >>> break; >>> else { >>> >>> >>> sgc_type_map[i] = 4; >>> } >>> first_protectable_page= ((i) - (i % page_multiple)); >>> } >>> if(page_multiple> 1) >>> fix_for_page_multiple(first_protectable_page,end); >>> >>> if (on==0) {sgc_mprotect((first_protectable_page), >>> (end - first_protectable_page), (4 | 1)); >>> install_segmentation_catcher(); > > > Impossible to say without knowing what install_segmentation_catcher(), > and presumably the SIGSEGV handler as well, are doing. > > It could be many things. Single stepping through the code after the > SIGSEGV with a recent gdb should shed some light on what is happening. > > David Daney > > >>> return; >>> } >>> >>> >>> >>> >>> >>> do {static struct sigaction action; >>> action.__sigaction_handler.sa_handler = (void *)memprotect_handler; >>> action.sa_flags = 0x10000000|0x00000008; sigemptyset(&action.sa_mask); >>> sigaddset(&action.sa_mask,2); sigaddset(&action.sa_mask,14); >>> sigaction(11,&action,0); sigaction(10,&action,0);} while (0); >>> beg=first_protectable_page; >>> writable = (((unsigned long)beg<(128*1024*(4>>2)/(1<<(14 -12))))&& >>> (sgc_type_map[beg]& (4 | 1))); >>> for (i=beg ; ++i<= end; ) { >>> int wri = (((unsigned long)i<(128*1024*(4>>2)/(1<<(14 -12))))&& >>> (sgc_type_map[i]& (4 | 1))); >>> if ((wri==0&& writable) >>> || (writable ==0&& wri) >>> || i == end) { >>> >>> if (writable) >>> make_writable(beg,i); >>> else >>> sgc_mprotect(beg,i-beg,writable); >>> writable = wri; >>> beg = i; >>> } >>> } >>> } >>> >>> >>> with the following strace: >>> >>> lstat64("/usr/lib/gcl-2.6.7/unixport/saved_gcl", {st_mode=S_IFREG|0755, >>> st_size=9231344, ...}) = 0 >>> personality(0xffffffff /* PER_??? */) = 0 >>> rt_sigaction(SIGSEGV, {0x18000008, [RT_68 RT_71 RT_75 RT_80 RT_81 RT_85 >>> RT_86 RT_87 RT_88 RT_90 RT_92 RT_94], SA_SIGINFO|0x422fe4}, NULL, 16) = 0 >>> getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 >>> getrlimit(RLIMIT_DATA, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0 >>> --- SIGSEGV (Segmentation fault) @ 0 (0) --- >>> rt_sigaction(SIGSEGV, {0x18000008, [RT_69 RT_72 RT_75 RT_76 RT_82 RT_84 >>> RT_85 RT_86 RT_88 RT_89 RT_90 RT_91 RT_92 RT_93 RT_94], >>> SA_SIGINFO|0x422fe4}, NULL, 16) = 0 >>> --- SIGSEGV (Segmentation fault) @ 0 (0) --- >>> +++ killed by SIGSEGV +++ >>> Segmentation fault >>> >>> The working -62 binary, built on and installed in my home on phrixos, >>> has the following strace: >>> >>> personality(0xffffffff /* PER_??? */) = 0 >>> rt_sigaction(SIGSEGV, {0x18000008, [RT_68 RT_71 RT_75 RT_80 RT_81 RT_85 >>> RT_86 RT_87 RT_88 RT_90 RT_92 RT_94], SA_SIGINFO|0x422fe4}, NULL, 16) = 0 >>> getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 >>> getrlimit(RLIMIT_DATA, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0 >>> mprotect(0xab8000, 1949696, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 >>> rt_sigaction(SIGSEGV, {0x18000008, [RT_67 RT_68 RT_70 RT_71 RT_72 RT_74 >>> RT_76 RT_77 RT_78 RT_80 RT_83 RT_84 RT_86 RT_87], SA_SIGINFO|0x422fe4}, >>> NULL, 16) = 0 >>> getrlimit(RLIMIT_DATA, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0 >>> sigaltstatck({ss_sp=0x6cbe98, ss_flags=0, ss_size=2097152}, NULL) = 0 >>> >>> The only thing I can spot is the RT_ flag difference in the second >>> sigaction call. But both these faults occur inside of sigaction (it >>> appears), so my working guess is that the c libraries are binary >>> incompatible across some of the the mipsel buildds. >>> >>> I would need access to two different machines to be able to compile >>> with debugging on for further info. But I hope the above is enough. >>> >>> Take care, >>> >>> Andreas Barth<[email protected]> writes: >>> >>>> * Camm Maguire ([email protected]) [100719 18:20]: >>>>> Greetings! Is is possible the sigaction semantics have changed on >>>>> mipsel recently, and that rem might be running in an older >>>>> compatibility mode? >>>>> >>>>> I've rebuilt gcl from the same -60 source on phrixous, and all appears >>>>> flawless. The older binary appears to be faulting on starup around an >>>>> attempted sigaction trap of SIGSEGV and SIGBUS (no debugging symbols). >>>>> Any way I can replace the -60 mipsel deb in the archive without >>>>> forcing a rebuild everywhere else? >>>> >>>> You can upload an +b1-package built by hand. Alternativly, if it can >>>> build automatically, I can schedule an binNMU. >>>> >>>> >>>> Andi >>>> >>>> >>>> >>>> >>> >>> -- >>> Camm Maguire >>> [email protected] >>> ========================================================================== >>> "The earth is but one country, and mankind its citizens." -- Baha'u'llah >>> >> >> ============================================================================= >> > > > > > -- Camm Maguire [email protected] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
