mips and proprietary instructions

JB general at itpsg.com
Sun Mar 25 19:40:58 UTC 2007


Thanks for the response...

The kernel is not the problem.  The processor will execute them if and 
when encountered.  The compiler already does not emit them.  It is the 
memcpy.S code distributed in any version of uClibc > 0.9.26 that has 
them already in assembly form.  I would be rewriting the mips assembly 
and the last mips assembly I worked on was many many years ago.  I would 
have thought the open source community would have opposed the 
proprietary instructions and worked to avoid them in the first place... 
Has no one dealt with this?  I searched on google for quite a while and 
was unable to find any kind of existing solution out there.



Will Newton wrote:
> On 3/25/07, JB <general at itpsg.com> wrote:
>> Hi all,
>>
>> I am using the realtek SDK which ships with precompiled binary versions
>> of uClibc 0.9.26.  I am attempting to get some version iproute2 working
>> on my radio.  After compiling tc, running it on the radio causes a
>> segfault.  At first I had a hard time figuring out where it was coming
>> from but eventually discovered it was a problem with the dl* system 
>> calls.
>>
>> I read that 0.9.27 and greater have improved that part of the library.
>> The version of gcc in the realtek SDK is 3.3.3.  I figured I would be
>> better off upgrading to a newer version of the library than rewriting an
>> older version tc in iproute2.
>>
>> When it goes to compile memcpy.S the compiler gives an error containing
>> "unrecognized opcode" when it encounters those instructions.  I have
>> done some web searching and I understand there is a very round about way
>> to emulate the same instructions with a lengthy series of other
>> instructions but I am not very familiar with MIPS assembly.
>>
>> Has anyone else seen this problem?  How have you dealt with it?
>
> There are kernel patches available (google for linux kernel lexra)
> that will trap and fixup the unaligned load/store instructions. The
> alternative is to patch your gcc and binutils to not generate these
> intsructions and fix any inline assembler - which is a bigger job but
> will result in better runtime performance.




More information about the uClibc mailing list