similar to: [PATCH 0/2 v3] mkstemp() and m68k support

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

retitle 925358 qemu-user-static: mis-emulates something to do with process/signal handling (m68k, s390x, ?) affects 925358 klibc-dev thanks This still happens. (And retitling because I almost filed a bug against klibc again? oops?) Look for ?mtest-external? (second occurrence) in: https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=m68k&ver=59c-16&stamp=1643675884&raw=0

Hello, I'm trying to port RPL/2 (http://www.rpl2.net) to OS/2 and I don't understand OS/2 semget(). RPL/2 uses POSIX semaphores. I have written a minimal library that emulates POSIX semaphores with SysV ones. I have tested this library on several Unix systems without any trouble. On OS/2, semget() always returns -1 and I don't understand my mistake. int sem_init_SysV(sem_t

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

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

This uses time, ASLR and pid for randomisation. (Closes: #516774) Signed-off-by: Thorsten Glaser <tg at mirbsd.org> --- usr/include/stdlib.h | 2 + usr/klibc/Kbuild | 2 +- usr/klibc/mkstemp.c | 93 ++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 96 insertions(+), 1 deletions(-) create mode 100644 usr/klibc/mkstemp.c diff --git a/usr/include/stdlib.h

Dixi quod? >Builtins work fine, calling external programmes does >not. It seems to hang in jobs.c:j_waitj() and sending >it SIGCHLD seems to not trigger jobs.c:j_sigchld() >at all. This is probably some kind of signals being >not delivered correctly ? see here for a bug with the >same symptoms: http://dev.haiku-os.org/ticket/5567 >http://dev.haiku-os.org/changeset/35836 >

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:

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:

On Tue, 2022-02-01 at 16:23 +0000, Thorsten Glaser wrote: > retitle 925358 qemu-user-static: mis-emulates something to do with process/signal handling (m68k, s390x, ?) > affects 925358 klibc-dev > thanks > > This still happens. (And retitling because I almost filed a bug > against klibc again? oops?) > > Look for ?mtest-external? (second occurrence) in: >

Hello, While some people might scuba dive, let's summarize recent progress and state (People cc'ed have either patches in queue or are involved): * Patches pending review, allmost ready for klibc ------------------------------------------------- - mikew/drop_cap - kinit: Add drop_capabilities support adds the ability to kinit to allow the dropping of POSIX capabilities. (patch even

On Sun, 2019-01-20 at 14:18 +0000, Thorsten Glaser wrote: > Hi Ben, > > *massive* thanks for picking up klibc work. This might motivate > me to pick up some of the TODOs for it that have piled on in my > TODO (but only after the freeze, I?m sorry to say, I have more > to do for other packages). > > >And I spotted another test program that has this property >

Hi, no mailing list for powerpcspe? What?s the progress of your architectures? I don?t see much happening on debian-ports.org, and taking your architectures off that infrastructure hurts others (I?ve ?revived? m68k and kept it running on d-p.o which helps a bit). Anyway: a new klibc (2.0~rc5-1) has been uploaded, and an mksh companion version (40.9.20120518-1) depending on it and trying to use

Hi All: We have some patches to port klibc to ArmV8. The first set of patches from Neil Williams fixes the build issues. The second set of patches from Anil Singhar fixes functionalities. The following files have changed in the second set of patches ------------------------------------------------------------------------------------------ usr/include/arch/aarch64/klibc/archconfig.h

I think it's time to issue an official call for anything missing in klibc 2.0... testing would also be appreciated. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.

Hi, number three, where I first thought it was a GCC bug but is apparently bad code in klibc. Submitted with permission: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47533#c6 Patch attached again (sorry) not just because that is easier with my mail system but also to keep original author intact. bye, //mirabilos -- > emacs als auch vi zum Kotzen finde (joe rules) und pine f?r den einzig >

On Thu, Jun 25, 2020 at 01:04:29PM +0300, Dan Carpenter wrote: > On Wed, Jun 24, 2020 at 12:39:24PM -0700, Kees Cook wrote: > > On Wed, Jun 24, 2020 at 07:51:48PM +0300, Dan Carpenter wrote: > > > In Debian testing the initrd triggers the warning. > > > > > > [ 34.529809] process '/usr/bin/fstype' started with executable stack > > > >

Hi, after changing mksh to no longer use mkstemp, I decided to try and build mksh-static with klcc on most platforms, in Debian. Here are the results by Debian architecture: alpha (4) fails amd64 works armel works armhf (3) fails i386 works ia64 works m68k (1) workaround mips works mipsel works powerpc (2) fails ppc64 works (!) s390 works s390x works sparc works Architectures not listed either

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

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: