similar to: [PATCH] use 2.6 module syscalls in klibc

--9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I stripped down the insmod command from modules-init-tools for use with klibc. Rusty agreed to have this contributed to klibc. The second patch removes old style modules support. -- ciao, Marco --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment;

Here is some timing information from running the Zig standard library tests: $ ./zig test ../std/index.zig --enable-timing-info Name Start End Duration Percent Initialize 0.0000 0.0010 0.0010 0.0001 Semantic Analysis 0.0010 0.9968 0.9958 0.1192 Code Generation 0.9968 1.4000 0.4032

Peter, current klibc does not compile in ia64: gcc -Wp,-MT,arch/ia64/pipe.o,-MD,arch/ia64/.pipe.o.d -Os -fomit-frame-pointer -nostdinc -iwithprefix include -D__KLIBC__ -DBITSIZE=64 -I../include/arch/ia64 -I../include/bits64 -I../include -I../linux/include -I../linux/include2 -I../linux/include -DWITH_ERRLIST -W -Wall -Wpointer-arith -Wwrite-strings -Wstrict-prototypes -Winline -c -o

Factor out all kernel specific path's (those containing usr/) into two variables: KLIBSRC + KLIBINC. Set the variables in a kernel spcific Kbuild file. Sam commit e6f989c1597a837f4aecbd11083697184c089611 tree 93f88d7564bb9e4d4bc95fd455b842d0bd0fdc54 parent 8151f4a98f82fba4fe3b949f49da4ab8bba71501 author Sam Ravnborg <sam@mars.(none)> Thu, 28 Jul 2005 23:36:07 +0200 committer Sam

* WARNING: Backward-incompatibility! The '$?' variable now contains all prerequisites that caused the target to be considered out of date, even if they do not exist (previously only existing targets were provided in $?). --- usr/klibc/socketcalls/Kbuild | 3 +++ usr/klibc/syscalls/Kbuild | 3 +++ 2 files changed, 6 insertions(+), 0 deletions(-) diff --git

Pipe's a strange syscall. Here is a fix for ia64. mh -- Martin Hicks Wild Open Source Inc. mort@wildopensource.com 613-266-2296 # This is a BitKeeper generated patch for the following project: # Project Name: The kernel C library # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: #

When using -fPIE/PIC with function tracing, the compiler generates a call through the GOT (call *__fentry__ at GOTPCREL). This instruction takes 6 bytes instead of 5 on the usual relative call. If PIE is enabled, replace the 6th byte of the GOT call by a 1-byte nop so ftrace can handle the previous 5-bytes as before. Position Independent Executable (PIE) support will allow to extended the KASLR

Dump the IR before newgvn and run through opt -newgvn. It should crash. I'm not familiar with your frontend but you might want to use -mllvm -opt-bisect-limit. On Sep 17, 2017 1:06 PM, "Andrew Kelley" <superjoe30 at gmail.com> wrote: Valgrind is strictly better than address sanitizer, is that right? It runs valgrind-clean: [nix-shell:~/dev/zig/build-llvm5-debug]$ valgrind

When zig updated to llvm 5 we started hitting this assertion: zig: /home/andy/downloads/llvm-project/llvm/include/llvm/Support/Casting.h:106: static bool llvm::isa_impl_cl<To, const From*>::doit(const From*) [with To = llvm::Instruction; From = llvm::Value]: Assertion `Val && "isa<> used on a null pointer"' failed. I wonder if however this was caused by an

Can you please open a bug on bugzilla and attach the ir testcase? Your fix doesn't look right (just hiding the assertion failure) On Sep 17, 2017 10:45 AM, "Andrew Kelley via llvm-dev" < llvm-dev at lists.llvm.org> wrote: > What do you think about this patch? > > --- a/llvm/lib/Transforms/Scalar/NewGVN.cpp > +++ b/llvm/lib/Transforms/Scalar/NewGVN.cpp > @@

On 11/08/2013 09:12 AM, Steve Capper wrote: > diff --git a/usr/klibc/lstat.c b/usr/klibc/lstat.c > new file mode 100644 > index 0000000..0282eec > --- /dev/null > +++ b/usr/klibc/lstat.c > @@ -0,0 +1,17 @@ > +#include <fcntl.h> > +#include <unistd.h> > +#include <sys/types.h> > +#include <sys/stat.h> > +#include <sys/syscall.h> > +

On 11/08/2013 09:12 AM, Steve Capper wrote: > diff --git a/usr/klibc/open64.c b/usr/klibc/open64.c > new file mode 100644 > index 0000000..6ca603e > --- /dev/null > +++ b/usr/klibc/open64.c > @@ -0,0 +1,22 @@ > +/* > + * open64.c > + * > + * For 64 bit systems without the open syscall, pass straight > + * through into openat. > + */ > + > +#define

In-Reply-To: <20060803002518.190834642@xensource.com> On Wed, 02 Aug 2006 17:25:13 -0700, Jeremy Fitzhardinge wrote: > We allow for the fact that the guest kernel may not run in ring 0. > This requires some abstraction in a few places when setting %cs or > checking privilege level (user vs kernel). I made some changes: a. Added some comments about the SEGMENT_IS_*_CODE() macros.

In-Reply-To: <20060803002518.190834642@xensource.com> On Wed, 02 Aug 2006 17:25:13 -0700, Jeremy Fitzhardinge wrote: > We allow for the fact that the guest kernel may not run in ring 0. > This requires some abstraction in a few places when setting %cs or > checking privilege level (user vs kernel). I made some changes: a. Added some comments about the SEGMENT_IS_*_CODE() macros.

Commit-ID: cd5927c02749b7c9d58b5144586505c85b903c27 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=cd5927c02749b7c9d58b5144586505c85b903c27 Author: H. Peter Anvin <hpa at zytor.com> AuthorDate: Mon, 21 May 2012 10:21:21 -0700 Committer: H. Peter Anvin <hpa at zytor.com> CommitDate: Mon, 21 May 2012 10:24:45 -0700 [klibc] SYSCALLS.def: add openat() on 64-bit

klibc fails to build on ia64 because it has neither fork nor the ppoll syscalls. This patch marks the former in SYSCALLS.def, and puts a guard wrapper around the ppoll definition in ppoll.c Should these calls return ENOSYS rather than simply not existing on some systems? If yes, please apply this and I'll follow up with a patch shortly that does ENOSYS for this and pselect at least.

Source: klibc Version: 2.0.2 Severity: important Tags: Patch On the hppa arch (32bit userspace and 32 or 64bit kernel), the fstype program fails to detect the filesystem. The reason for this failure is, that fstype calls the pread() syscall, which has on some architectures with 32bit userspace a different calling syntax. I noticed this bug on hppa, but I assume s390 (32bit) and others might run

Hello! Perhaps someone can give me a good answer to this question. Please give me a direct answer, I have allready been trouh the wine FAQ:s , docs, code, etc. I know DOS syscalls is made using interupts (int instruction) but, is Windows/NT syscalls made the same way. How does wine stop these instructions from reaching the unix kernel?

Hi, I was trying to determine how Wine captures syscalls, and I found this thread: http://www.winehq.org/pipermail/wine-users/2002-October/009077.html The answer was that Wine *doesn't* deal with syscalls, and relies on the application never directly making a syscall, but instead calling into the standard system libraries (Win32). Is this still true today? I'm surprised that Wine can

The finit_module() system call was merged in Linux 3.8. This system call is similar to init_module(), but it allows to load Linux kernel modules from file descriptors. Signed-off-by: Nikita Ermakov <sh1r4s3 at mail.si-head.nl> --- usr/klibc/SYSCALLS.def | 1 + 1 file changed, 1 insertion(+) diff --git a/usr/klibc/SYSCALLS.def b/usr/klibc/SYSCALLS.def index c8ac9e0d..7a67b01f 100644 ---