similar to: klibc: s390 errno...

Displaying 20 results from an estimated 4000 matches similar to: "klibc: s390 errno..."

2011 Jan 29
1
[PATCH] Re: klibc barfs on m68k syscall interface
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
2012 May 15
5
[PATCH 0/5] resubmitting pending patches
Hi, I?ve gone through the mailing list archives and hereby want to resubmit my pending patches. Most are independent of each other, except the m68k patch which will only be complete if sigsuspend is also fixed. (It can be applied before that, though.) http://www.zytor.com/pipermail/klibc/2012-January/003173.html [PATCH] fix m68k support Resubmitted here as 0005. While there was a question from
2006 Jun 07
4
[patch] s390: vfork support
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
2012 Jan 29
5
[PATCH 0/2 v3] mkstemp() and m68k support
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
2006 Jun 28
35
[klibc 00/31] klibc as a historyless patchset (updated and reorganized)
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:
2017 Dec 30
6
building debug version of klibc
Hello! Can someone please help me in building debug version of klibc ? I've cloned git://git.kernel.org/pub/scm/libs/klibc/klibc.git , but failed to build it with debug info added "-g" to HOSTCFLAGS in Makefile, but $ make -j KLIBCKERNELSRC=`pwd`/../linux-2.6/usr still strips every debug symbol , and i'm failed to change scripts/Kbuild.klibc and Makefile to remove strip
2006 May 24
1
[patch] klibc: merge s390/s390x 2nd try
From: Heiko Carstens <heiko.carstens@de.ibm.com> Merge s390 and s390x into s390. Patch is against current linux-2.6-klibc tree and seems to work. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> --- As a side note: a bitops patch is missing to make this working. Martin will send it soon. If it's needed earlier I can send it as well. Makefile
2020 Jul 27
3
[PATCH] Add syscall wrappers required by libkeyutils
On Saturday, 25 July 2020, 23:36:33 CEST, Ben Hutchings wrote: > On Wed, 2020-07-08 at 08:37 +0200, Christian Eggers wrote: > > ... > > libkeyutils usually invokes syscall() directly. As syscall() is not > > provided by klibc, libkeyutils has to be slightly modified for using the > > klibc wrappers. > > Wouldn't it be more useful for klibc to implement
2013 Nov 11
5
[PATCH V2 0/3] Introduce arm64 support
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
2014 Mar 11
4
[PATCH] add mips64 support
From: Dejan Latinovic <Dejan.Latinovic at imgtec.com> --- usr/include/arch/mips64/klibc/archconfig.h | 3 + usr/include/arch/mips64/klibc/archsetjmp.h | 39 ++++++ usr/include/arch/mips64/machine/asm.h | 76 ++++++++++ usr/include/fcntl.h | 2 +- usr/include/sys/md.h | 1 + usr/include/sys/resource.h | 4 +-
2013 Nov 08
9
[PATCH 0/3] Introduce arm64 support
Hello, This series introduces arm64 support to klibc. I've rebased the work from Neil Williams and Anil Singhar into the following three patches. Most of the code changes are due to new syscall implementations being needed for arm64 as a only a minimal set of syscalls are defined in the arm64 kernel. This series is to be applied against the latest klibc, just after 25a66fa README.klibc:
2018 Jul 17
1
[PATCH klibc 1/2] rename, renameat: Use renameat2() system call
New architectures only define the renameat2() system call, which was added in Linux 3.15. Define rename() and renameat() as wrappers for it if necessary. Signed-off-by: Ben Hutchings <ben at decadent.org.uk> --- --- a/usr/klibc/Kbuild +++ b/usr/klibc/Kbuild @@ -59,7 +59,8 @@ klib-y += vsnprintf.o snprintf.o vsprint inet/inet_ntoa.o inet/inet_aton.o inet/inet_addr.o \
2020 Jul 08
2
[PATCH] Add syscall wrappers required by libkeyutils
libkeyutils is used by the keyctl command which is required for loading keys into the kernel (e.g. for mounting an authenticated UBIFS as root file system). libkeyutils usually invokes syscall() directly. As syscall() is not provided by klibc, libkeyutils has to be slightly modified for using the klibc wrappers. Signed-off-by: Christian Eggers <ceggers at arri.de> ---
2006 Jun 26
5
__builtin_clz in klibc
Hi, I just got a bug report that klibc doesn't compile on s390: KLIBCCC usr/klibc/libgcc/__clzsi2.o KLIBCCC usr/klibc/libgcc/__clzdi2.o usr/klibc/libgcc/__clzdi2.c: In function `__clzdi2': usr/klibc/libgcc/__clzdi2.c:24: warning: implicit declaration of function `__builtin_clz' This looks like a common problem, because __builtin_clz is available since gcc 3.4, while the kernel
2004 Jun 23
4
CRIS port of klibc
klibc now runs on the CRIS archtitecture. The patch below is against 0.146. Most of the changes are trivial but the new files in libgcc requires some comments. __negdi2.c: The CRIS port fallbacks to C-code for negdi2. The code in __negdi2.c is copied from libgcc2.c but with modified typenames. I would really appreciate if someone could check if it seams sane. crisarith.c: CRIS has no built-in
2012 May 25
4
klibc breakage on alpha, need porterbox
Hi, is there a DD-accessible porterbox somewhere (slow would be ok, as this is smallish software) with an up-to-date sid (enough to install the recently-built libklibc-dev 2.0~rc5-1 and all other B-D of mksh 40.9.20120518-1, as well as strace and gdb-minimal)? Similarily to http://www.zytor.com/pipermail/klibc/2012-May/003229.html I found klibc-compiled programmes on Alpha to fail (SIGSEGV
2019 Jan 20
3
RFT: klibc 2.0.5
On Sun, 2019-01-20 at 04:37 +0000, Ben Hutchings wrote: [...] > ppc/powerpc-linux-gnu: pass fail: malloctest2*, > setjmptest*, sigint* [...] > s390x/s390x-linux-gnu: fail: fcntl fail: malloctest2*, setjmptest* setjmptest*, >
2013 Aug 21
3
Build problems: klibc with Linux 3.10.7
On Wed, Aug 21, 2013 at 06:48:08PM +0200, maximilian attems wrote: > On Wed, Aug 21, 2013 at 06:03:41PM +0200, leroy christophe wrote: > > > > Note that step B is working well. > > It is step C, the 'make install', which fails. > > right, it is the toplevel Makefile one needs to poke for the target. > see belows proper patch: >From
2019 Jan 19
4
RFT: klibc 2.0.5
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:
2006 May 30
3
vfork support: need help on arm, parisc, s390
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,