Hi klibc people, if someone has to say more on this, please do so. I?m only trying to explain what I _think_ I learned?>Begin forwarded message originally by Mike Frysinger:>> On Mon, Mar 21, 2011 at 10:24 AM, Waldemar Brodkorb wrote:>>> unfortunately the common vfork implementation, which just use >>> the syscall function to interact with the kernel, does not work >>> on the cris architecture. The system call vfork is special, on most >>> architectures just calling syscall is not enough. >>> The patch below adds the vfork implementation from klibc.>> this lacks an explanation as to why vfork is so special on cris.I think vfork is special on most architectures. Both i386 and m68k klibc vfork.S files contain this comment: # vfork is nasty - there must be nothing at all on the stack above # the stack frame of the enclosing function. The generic syscall handler probably (klibc?s does) pushes some register(s), like this: push $srp Ah, yes. ?Clibc does this as well: subq 4,sp and push srp so it?s done in both cases of the ifdef. I think this is because it may directly manipulate things.>> different calling convention ? different return values ? somethingI think it?s sort of a different calling-returning convention.>> your simple implementation is probably incorrect -- errno cannot be >> referenced directly.Mh. On the other hand, the manpage says: In a multithreaded application, vfork() borrows only the thread of control that called vfork() in the parent; that is, the child contains only one thread. The use of vfork() in multithreaded applications, however, is unsafe due to race conditons that can cause the child process to become deadlocked and consequently block both the child and parent process from execution indefinitely. But if that?s a concern? fix it ? Waldemar is an integrator, not a libc hacker. He found a problem and a WFM-style fix, which at least improves the situation. By all means, replace the errno access with a jump to __syscall_error after setting up registers in a way that routine (from sysdeps/linux/cris/sysdep.S) expects it; I don?t know cris assembly but it doesn?t look _too_ hard? bye, //mirabilos -- FWIW, I'm quite impressed with mksh interactively. I thought it was much *much* more bare bones. But it turns out it beats the living hell out of ksh93 in that respect. I'd even consider it for my daily use if I hadn't wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh
On Mon, Mar 21, 2011 at 11:14 AM, Thorsten Glaser wrote:>>> your simple implementation is probably incorrect -- errno cannot be >>> referenced directly. > > Mh. On the other hand, the manpage says: > > ? ? In a multithreaded application, ?vfork() ?borrows ?only ?the > ? ? thread ?of ?control ?that called vfork() in the parent; that > ? ? is, the child contains only one thread. The use ?of ?vfork() > ? ? in ?multithreaded ?applications, ?however, ?is unsafe due to > ? ? race conditons that can cause the child ?process ?to ?become > ? ? deadlocked ?and consequently block both the child and parent > ? ? process from execution indefinitely.which is irrelevant in the case of updating errno -- the vfork failed and thus no 2nd process is running> But if that?s a concern? fix iti have nothing to do with cris. but the answer here is not "fix it" but rather "patch not merged". no sweat off my back since i dont have any cris hardware.> He found a problem and a WFM-style fix, which at > least improves the situation.then file a bug in bugzilla so someone else will fix it eventually> By all means, replace the errno > access with a jump to __syscall_error after setting up registers > in a way that routine (from sysdeps/linux/cris/sysdep.S) expects > it; I don?t know cris assembly but it doesn?t look _too_ hard?tailing to __syscall_error is probably a wise decision -mike
Hi, On Mar 21, 2011, at 6:01 PM, Mike Frysinger wrote:> On Mon, Mar 21, 2011 at 11:14 AM, Thorsten Glaser wrote: >>>> your simple implementation is probably incorrect -- errno cannot be >>>> referenced directly. >> >> Mh. On the other hand, the manpage says: >> >> In a multithreaded application, vfork() borrows only the >> thread of control that called vfork() in the parent; that >> is, the child contains only one thread. The use of vfork() >> in multithreaded applications, however, is unsafe due to >> race conditons that can cause the child process to become >> deadlocked and consequently block both the child and parent >> process from execution indefinitely. > > which is irrelevant in the case of updating errno -- the vfork failed > and thus no 2nd process is running > >> But if that?s a concern? fix it > > i have nothing to do with cris. but the answer here is not "fix it" > but rather "patch not merged". no sweat off my back since i dont have > any cris hardware.I already asked about the problem here: http://www.mail-archive.com/uclibc at uclibc.org/msg06089.html Unfortunately it is your commit, which breaks it for the unpopular cris architecture: ------------- commit 711ad9f92c1cf992c4a3d9f4f709bd692be7789c Author: Mike Frysinger <vapier at gentoo.org> Date: Thu Jul 23 04:03:17 2009 -0400 create real common vfork() function Rather than force people to always implement their own vfork(), have the default implementation be sane. For now, only the Blackfin port uses the new code. -------------> >> He found a problem and a WFM-style fix, which at >> least improves the situation. > > then file a bug in bugzilla so someone else will fix it eventuallySo getting the info of my two mails into a bug report is the best way to get a working uclibc for my two Foxboards? They are old, but still nice, f.e. as a kerberos master. Just as a side note, after one of the suggested fixes, the cris embedded system runs fine: root at brom:/root # uptime 20:11:01 up 40 days, 3:38, load average: 0.08, 0.03, 0.05 root at brom:/root # uname -a Linux brom 2.6.37 #1 Tue Feb 1 01:28:39 CET 2011 cris GNU/Linux root at brom:/root # ps axw|grep krb 288 root /usr/sbin/krb5kdc 601 root grep krb root at brom:/root # ls /lib/libuClibc-0.9.32-rc2.so /lib/libuClibc-0.9.32-rc2.so have fun Waldemar
On Tue, Mar 22, 2011 at 3:15 PM, Waldemar Brodkorb wrote:> On Mar 21, 2011, at 6:01 PM, Mike Frysinger wrote: >> i have nothing to do with cris. ?but the answer here is not "fix it" >> but rather "patch not merged". ?no sweat off my back since i dont have >> any cris hardware. > > I already asked about the problem here: > http://www.mail-archive.com/uclibc at uclibc.org/msg06089.html > > Unfortunately it is your commit, which breaks it for the unpopular cris architecture:if you actually read the code, before my commit, vfork() wasnt a vfork(). it was a fork(). so no, my commit didnt "break" cris. it was already broken.>> then file a bug in bugzilla so someone else will fix it eventually > > So getting the info of my two mails into a bug report is the best way to get > a working uclibc for my two Foxboards?if you arent going to fix the issue yourself, then yes -mike