Re: binary incompatibility among mipsel buildds
Greetings!
Andreas Barth <aba@not.so.argh.org> writes:
> Hi,
>
> I need to admit: ugh. I'm by far not an porter enough for this, but
> please send your results to d-mips@l.d.o. 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 <ddaney@caviumnetworks.com> 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 d-mips@l.d.o. 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 (camm@maguirefamily.org) [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<aba@not.so.argh.org> writes:
>>>
>>>> * Camm Maguire (camm@maguirefamily.org) [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 camm@maguirefamily.org
>>> ==========================================================================
>>> "The earth is but one country, and mankind its citizens." -- Baha'u'llah
>>>
>>
>> =============================================================================
>>
>
>
>
>
>
--
Camm Maguire camm@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Reply to: