similar to: Bug#634890: klibc issues on armhf (not Debian/armel)

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

Commit-ID: d7d16afbdae9bdea83aeb26ac572e6fc4d7d4940 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=d7d16afbdae9bdea83aeb26ac572e6fc4d7d4940 Author: Steve McIntyre <steve at einval.com> AuthorDate: Fri, 29 Jun 2012 18:13:34 +0100 Committer: maximilian attems <max at stro.at> CommitDate: Sun, 1 Jul 2012 22:51:00 +0200 [klibc] arm/setjmp.S: fix longjmp

[klibc] [PATCH] fix ARM longjmp with zero 'val'. We need to set the condition codes on the ARM. The previous version was using a left over condition code from the caller. Also, use conditional execution to eliminate branch and reduce size. Signed-off-by: Bill Pringlemeir <bpringle at sympatico.ca> diff --git a/usr/klibc/arch/arm/setjmp.S b/usr/klibc/arch/arm/setjmp.S index

Hi, we?re currently seeing trouble with klibc on several architectures, cf. http://www.zytor.com/pipermail/klibc/2012-May/003277.html and armhf is being one of them, when using klibc to compile mksh-static with it. I can look into it (asked zumbi for build-deps in a sid chroot on harris already), but not 100% sure I?ll find it, so more eyes on klibc would not be unwelcome ;-) maks, does 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:

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 \

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:

m68k is the only debian arch still lacking a klibc port... So I started working on this tonight, despite not knowing anything about the m68k. Puzzling out the details, and disassembling things, I've at least got a syscall.c that looks like it might work. I don't really have time to do this bring up, but maybe someone else would like to finish the work. I guess this needs at least,

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

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

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

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

Klibc FTBFS with '-mno-odd-spreg' on mips32(el) platforms, As it try to save/restore odd-number FPR. Indeed no other architectures save/restore FPR at all. It shouldn't be needed. --- usr/klibc/arch/mips/setjmp.S | 24 ------------------------ 1 file changed, 24 deletions(-) diff --git a/usr/klibc/arch/mips/setjmp.S b/usr/klibc/arch/mips/setjmp.S index 68eed19..21e4115 100644 ---

On Wed, Sep 15, 2004 at 10:48:02AM +0930, Alan Modra wrote: > After using SHAREDFLAGS = -Ttext 0x0f000200 on ppc64 (which I see you > suggested in another email), I see the problem you're talking about. > > klibc is fundamentally broken on ppc64. You just can't call into > another chunk of code (klibc.so in this case) which has a separate toc > and expect things to

Hi, I have some code which has sigsetjmp / longjmp. After a longjmp, unreachable is inserted, which is fine. The problem is that in the backend before calling longjmp, some register was spilled to a stack location which is live across the jmp. I mean, it will be live after jumping. The stack location was initialized before the call to setjmp, and is used afterwards. Is there any bug in handling

Commit-ID: f05ff116bb9edbbb81d82fa47b78e630ce878470 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=f05ff116bb9edbbb81d82fa47b78e630ce878470 Author: Bill Pringlemeir <bpringle at sympatico.ca> AuthorDate: Tue, 2 Oct 2012 13:29:52 -0400 Committer: maximilian attems <max at stro.at> CommitDate: Wed, 3 Oct 2012 18:41:43 +0200 [klibc] [PATCH] fix ARM longjmp

On 28 April 2015 at 00:30, Reid Kleckner <rnk at google.com> wrote: > I think Paweł identified the problem. The frames on the stack between the > setjmp and longjmp must have valid unwind information, which is described > here: > https://msdn.microsoft.com/en-us/library/ft9x1kdx.aspx?f=255&MSPPError=-2147217396 > > In particular, it has this line about JITed code: >

On Oct 4, 2011, at 3:53 PM, Eli Friedman wrote: > On Tue, Oct 4, 2011 at 3:10 PM, Khaled ElWazeer > <khalid.alwazeer at gmail.com> wrote: >> Hi, >> >> I have some code which has sigsetjmp / longjmp. After a longjmp, unreachable >> is inserted, which is fine. The problem is that in the backend before >> calling longjmp, some register was spilled to a

Do the LLVM Setjmp/Longjmp intrinsics interact with C++ exception handling and execute C++ cleanup actions? I compiled a small example using setjmp/longjmp using clang and they did not execute C++ cleanup actions and calling longjmp bypassed calling destructors on objects that were allocated between the call to setjmp and longjmp. I’m wondering if the LLVM intrinsics behave differently from

I'm trying to make sense in the support for setjmp/longjmp in Clang and LLVM, with only partial success. I'll try to summarize my findings in the hope that someone can shed some light on why things are the way they are and what I'm missing. Clang. Clang recognizes two forms of setjmp (all I say here applies to longjmp similarly): * __builtin_setjmp: gets lowered to calling the