similar to: vfork support: need help on arm, parisc, s390

Implement "pid_t vfork(void)" for parisc. Signed-off-by: Kyle McMartin <kyle at parisc-linux.org> --- Ugh. vfork() me harder. Kbuild | 2 +- vfork.S | 31 +++++++++++++++++++++++++++++++ 2 files changed, 32 insertions(+), 1 deletion(-) diff --git a/usr/klibc/arch/parisc/Kbuild b/usr/klibc/arch/parisc/Kbuild index d57a873..57ca5c2 100644 --- a/usr/klibc/arch/parisc/Kbuild

If you have access to an Alpha, please test klibc-1.3.21; in particular, anything which uses pipes... Thanks, -hpa

Hi All, I has been trying to port the Samba package to uClinux. But our uClinux toolchain doesn't support the fork() call. I must replace the fork with vfork.If we use vfork, the smbd and nmbd can not work rightly. both samba-3.0.32 and samba-3.0.2a have the question. In samba/source/smbd/server.c, the function open_sockets_smbd(), creates a child process and a parent process. Both these

From: Heiko Carstens <heiko.carstens@de.ibm.com> vfork support for s390/s390x. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> --- diff -purN a/usr/klibc/SYSCALLS.def b/usr/klibc/SYSCALLS.def --- a/usr/klibc/SYSCALLS.def 2006-06-07 09:44:33.000000000 +0200 +++ b/usr/klibc/SYSCALLS.def 2006-06-07 13:01:54.000000000 +0200 @@ -28,7 +28,7 @@ void _exit,exit::_exit(int) ; A

Pipe doesn't work in dash on mips/mipsel - everything delivered to a pipe is shown on stdout: mipsel: $ echo foo | cat > ~/d foo <ctrl-c pressed manually> $ cat ~/d $ i386: $ echo foo | cat > ~/d $ cat ~/d foo $ This may be related to the following warnings during compilation but I'm not sure: klibc/arch/mips/syscall.S: Assembler messages: klibc/arch/mips/syscall.S:12:

Commit-ID: b71dd57f6a784962681ac05aa686b28db8668609 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=b71dd57f6a784962681ac05aa686b28db8668609 Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Mon, 21 Jan 2019 03:55:35 +0000 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Mon, 21 Jan 2019 03:55:35 +0000 [klibc] parisc: Fix vfork() The

In preparation for the klibc 2.0.5 release I wrote a basic test script which: 1. Builds for each architecture (with a cross-compiler where needed) 2. Runs several statically-linked programs (using qemu-user where needed): a. Many self-test programs b. "sh -c exit" c. "sh -c '.../bin/true; exit'" The results for the architectures I was able to test are:

When I compile klibc on little-endian mips, I get: KLIBCLD klibc/libc.so ld: klibc/arch/mips/crt0.o: compiled for a little endian system and target is big endian ld: klibc/arch/mips/crt0.o: endianness incompatible with that of the selected emulation ld: failed to merge target specific data of file klibc/arch/mips/crt0.o When I change "elf32-tradbigmips" to

Hello Kyle, May be out of context but before I forget: > > + > > + /* store %r22 to errno... */ > > + ldil L%errno,%r1 > > + ldo R%errno(%r1),%r1 Could it not be 'load32 errno, %r1' (the assembly.h macro)? Cheers, Joel ---------- Club Scarlet : Tout le monde gagne! Si vous devenez aujourd'hui Scarlet One grace a un client existant de Scarlet, vous

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

tag 334917 = patch thanks Hi, I?ve fixed the m68k syscall of klibc and made it able to use six-argument syscalls like mmap2. However, I could not yet fully test it (only mostly; opendir() specifically fails) due to: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47533 @m68k porters: Please have a look at the gcc bug as well. @klibc: Please apply the patch, it?s better than what we have, and

I have updated the klibc patchset based on feedback received. In particular, the patchset has been reorganized so as not to break git-bisect. Additionally, this updates the patch base to 2.6.17-git12 (d38b69689c349f35502b92e20dafb30c62d49d63) and klibc 1.4.8; the main difference on the klibc side is removal of obsolete code. This is also available as a git tree at:

Commit 8418552 ("[klibc] ia64: Fix shared build") missed this use of the GP register, although the code appears to have been dubious anyway, assuming the address of errno was the first thing pointed to by GP. --- usr/klibc/arch/ia64/vfork.S | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/usr/klibc/arch/ia64/vfork.S b/usr/klibc/arch/ia64/vfork.S index

hello vorlon, got notified of your patch, will apply next days upstream unless some critiques are voiced on ml. thanks. -- maks ----- Forwarded message from Steve Langasek <steve.langasek at canonical.com> ----- Date: Wed, 16 Feb 2011 22:05:42 -0000 From: Steve Langasek <steve.langasek at canonical.com> Subject: [Bug 527720] Re: thumb2 porting issues identified: klibc uses

This fixes a long standing issue where it was not possible to do "make usr/klibc/arch/x86_64/longjmp.o" in the kernel. The principle is that all .o files to be part of klibc are listed with klib-y. For each directory a klib.list file is made that specify all .o file and the final AR then adds all .o files to create libc.a. This patch introduce the infrastructure and converts x86_64 to

This was filed as a bug report on the Debian r-base package. It is more properly a bug report on the ctest package in R. The default method for wilcox.test manipulates x and y without checking the class or data.class of these objects. Possible solutions are - create wilcox.test.factor (if appropriate) - check the class and/or data.class of x and y in wilcox.test.default and produce error

Processing commands for control@bugs.debian.org: > reassign 368417 xen-hypervisor-3.0.2-1-i386 Bug#368417: xen-hypervisor-3.0-i386: cannot start NetBSD-HEAD Warning: Unknown package 'xen-hypervisor-3.0-i386' Bug reassigned from package `xen-hypervisor-3.0-i386' to `xen-hypervisor-3.0.2-1-i386'. > reassign 380333 xen-hypervisor-3.0.2-1-i386 Bug#380333:

I have just pushed out a git tree which actually has the root-mounting code removed from the kernel. Since there are any number of strange boot configurations out there, I would really appreciate any help in testing this stuff out. I have *NOT* implemented support for the following, which I'm hoping has fallen out of use by now: -> Setting boot flags via rdev, as opposed to on the

ok i have another problem - howto run asterisk as a daemon ( fork ) in uclibc enviroment ? uClinux can only do vfork() a i think this is problem... does anybody know how to solve this ? regards Marian -- SUNTEQ s. r. o. Bojnicka cesta 35 # Prievidza # 971 04 # Slovak republic Tel: +421-46-5430 754 # Fax: +421-46-5439 144 http://www.sunteq.sk/

Hello, Here is V2 of the arm64 support for klibc patch set. Notable changes since the original series: * fp regs dropped from setjmp/longjmp * chmod, lstat and stat re-implemented with *at functions. * open64 merged into open. As with the original, this series is to be applied against the latest klibc, just after 25a66fa README.klibc: update build information V2 has been tested on x86_64