uclibc 0.9.32rc1 for cris architecture

Khem Raj raj.khem at gmail.com
Thu Jan 20 20:50:43 UTC 2011


On Thu, Jan 20, 2011 at 12:06 PM, Waldemar Brodkorb <wbx at openadk.org> wrote:
> Hi,
> Khem Raj wrote,
>
>> On Sat, Jan 15, 2011 at 3:57 AM, Waldemar Brodkorb <wbx at openadk.org> wrote:
>> > Hi,
>> > Khem Raj wrote,
>> >
>> >> On Fri, Jan 14, 2011 at 6:45 AM, Waldemar Brodkorb <wbx at openadk.org> wrote:
>> >> > Hi Developers,
>> >> >
>> >> > I have a problem with 0.9.32-rc1 (with old linuxthreads) on my
>> >> > Foxboard LX.
>> >> > An older version of uClibc (0.9.30.3) works fine. After applying
>> >> > following patches from
>> >> > OpenWrt, I get 0.9.32-rc1 compiled:
>> >> > https://dev.openwrt.org/browser/trunk/toolchain/uClibc/patches-0.9.32/150-cris_missing_syscall_include.patch
>> >> > https://dev.openwrt.org/browser/trunk/toolchain/uClibc/patches-0.9.32/151-cris_add_sys_user_h.patch
>> >> >
>> >> > Starting a system from NFS does crash when calling mdev from
>> >> > busybox.
>> >> > After using git bisect, I found the bad commit
>> >> > 711ad9f92c1cf992c4a3d9f4f709bd692be7789c.
>> >> > Not only blackfin uses the new code, also cris pick it up. When I
>> >> > revert the commit, everything
>> >> > is fine again.
>> >> >
>> >> > Does anybody see the reason, why the code in trunk fails on cris?
>> >>
>> >> thanks for the report we should get these patches into rc2 and about vfork
>> >> does cris has __NR_vfork or does it have __ARCH_USE_MMU__ defined and __NR_fork
>> >
>> > libc/sysdeps/linux/common/vfork.c:14:2: warning: #warning __ARCH_USE_MMU__ is defined for cris
>> > libc/sysdeps/linux/common/vfork.c:17:2: warning: #warning __NR_fork is defined for cris
>> > libc/sysdeps/linux/common/vfork.c:21:2: warning: #warning __NR_vfork is defined for cris
>> >
>> > All three symbols are defined. But the syscall method is used. (_syscall0(pid_t, __vfork)
>> >
>>
>> OK so the difference is that before this commit vfork simply used
>> fork() for cris but now it uses vfork syscall
>> since it seems to have __NR_vfork defined which is right thing IMO. Is
>> this syscall wired up in your kernel ?
>
> I am using Linux 2.6.37 now, but it did not work for 2.6.36 neither.
> How to check if the syscall is wired
> up? At least in arch/cris/arch-v10/kernel/process.c is some code ;)
>
> The comment above the code is:
> /* vfork is a system call in i386 because of register-pressure - maybe
>  * we can remove it and handle it in libc but we put it here until then.
>  */
>
> Maybe the code is outdated and wrong, but never used, because it was
> implemented in uClibc. (eglibc/glibc is no longer available for cris
> architecture IIRC)

OK in that case you could try to fix the kernel implementation or we can
provide a cris specific implementation in uclibc where we will use fork() as
it used to be. I would suggest that if possible fix the kernel implementation
if its not too much hassle

>
> best regards
>  Waldemar
>


More information about the uClibc mailing list