similar to: fwd: fix up ARM assembly to use 'bx lr' in place of 'mov pc, lr'.

Use klibc way to define a system dependent preprocessor definition: disabled by default and enabled for newer arm. Based on a patch by vorlon that got tested on his beagleboard, should be functional equivalent. Fixes: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/527720 Cc: Steve Langasek <steve.langasek at canonical.com> Cc: Kirill A. Shutemov <kirill at shutemov.name> Cc:

The parts of klibc specific to the arm architecture. Signed-off-by: H. Peter Anvin <hpa at zytor.com> --- commit 1eff7c685b36cd0120694fd4150b32a26168d926 tree 953dd1dbd2e994fc27c6cf5708fcbe06fe000d58 parent 5e5ce29210ac33a0b3704eb9ab5e5d5b55375575 author H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun 2006 16:58:16 -0700 committer H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun

Package: klibc Version: 1.5.20-1 Severity: normal Tags: patch User: ubuntu-devel at lists.ubuntu.com Usertags: origin-ubuntu natty ubuntu-patch Hi maks, Since the Ubuntu linux-libc-dev is now installing its asm headers to the multiarch /usr/include/<triplet>/ directory to allow co-installability, I've pushed the attached patch to Ubuntu so klcc knows to include this path when searching

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:

Hi, llvm emits code for "memcpy" on ARM as consecutive ldr/str commands, and further combines them into ldm/stm with special pass after register allocation. But ldm/stm commands require registers to go in ascending order, what is often not so after regalloc, therefore some str/ldr commands. For example such code: struct Foo {int a, b, c, d; } void CopyStruct(struct Foo *a, struct

09.02.2011 18:57, Jason Kim пишет: > On Wed, Feb 9, 2011 at 5:02 AM, Vasiliy Korchagin > <vasiliy.korchagin at gmail.com> wrote: >> Hi, >> >> llvm emits code for "memcpy" on ARM as consecutive ldr/str commands, and > > Hmm, this happens elsewhere as well (x86?). Perhaps what we need is a > switch to disable memset/memcpy lowering? > Do you

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

Hello all, I really want to support vfork() in klibc, mostly because uClinux *has* to use it. Unfortunately vfork() isn't allowed to use the stack *at all* across the system call -- including return address -- which means it needs an assembly wrapper on most architectures. I have tried implementing wrappers for most architectures, but I don't know parisc or s390/s390x well enough,

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

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

-fno-builtin is the flag you want. deep On Wed, Feb 9, 2011 at 10:18 PM, Корчагин Василий <vasiliy.korchagin at gmail.com> wrote: > 09.02.2011 18:57, Jason Kim пишет: >> On Wed, Feb 9, 2011 at 5:02 AM, Vasiliy Korchagin >> <vasiliy.korchagin at gmail.com>  wrote: >>> Hi, >>> >>> llvm emits code for "memcpy" on ARM as consecutive

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

Hello- Shouldn't this catch swapcontext as well? Alistair On 26 May 2010, at 22:14, Dale Johannesen wrote: > > On May 26, 2010, at 2:05 PMPDT, Dan Gohman wrote: > >> vfork and getcontext have wildly platform-dependent semantics. >> Handling >> them conservatively is reasonable, even if some platforms don't need >> it. >> >> Dan >

On Wed, Feb 9, 2011 at 5:02 AM, Vasiliy Korchagin <vasiliy.korchagin at gmail.com> wrote: > Hi, > > llvm emits code for "memcpy" on ARM as consecutive ldr/str commands, and Hmm, this happens elsewhere as well (x86?). Perhaps what we need is a switch to disable memset/memcpy lowering? > further combines them into ldm/stm with special pass after register >

Steven Langasek wrote: > Having one PDC and two BDCs also gives you greater > fault-tolerance than > having three domains with a single PDC each. > > Samba+LDAP can give you this fault tolerance; it can't give you trust > relationships today, without a lot of finagling. > > Steve Langasek > postmodern programmer > Steve: I understand the role of/need for the

Hi all, As WinXP begins to loom larger in our environment, we're seeing a consistent pattern that XP machines (mostly XP Professional, possibly others) take an excessively long time to access shared printers: I'm told that it takes up to 5 minutes to initially install the printer on the local machine, and it typically takes around 45 seconds to deliver print jobs to the queue. The print

Hi, after a year, I decided to hack on klibc again. I?ve reworked both the patch to add mkstemp(), discussing to use AT_RANDOM as cheap entropy source on IRC (if there will ever be another entropy consumer, I can quickly write a minimal arc4random() seeded from it, as it has only 16 octets), capable of making a working mksh (static and shared) on amd64/xen, and the m68k support code, leading to

I didn't see swapcontext in the list in gcc's special_function_p function... -bw On May 26, 2010, at 2:20 PM, Alistair Lynn wrote: > Hello- > > Shouldn't this catch swapcontext as well? > > Alistair > > On 26 May 2010, at 22:14, Dale Johannesen wrote: > >> >> On May 26, 2010, at 2:05 PMPDT, Dan Gohman wrote: >> >>> vfork and

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

Hi there, I have a really ugly problem, which, as I know is partially selfmade. But to the problem: I have five servers running samba-2.2.3a-12 (latest Debian Woody release) which are controlled by one master server. All of the five servers act as pdc for an own nt-domain. Now to keep the administrative work as low as possible I have this one master server. Via this server we/our customer