similar to: [klibc 24/43] i386 support for klibc

Commit-ID: 9b625887a59c03c244b43550b576529f209dde11 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=9b625887a59c03c244b43550b576529f209dde11 Author: H. Peter Anvin <hpa at linux.intel.com> AuthorDate: Tue, 5 Jan 2016 16:43:50 -0800 Committer: H. Peter Anvin <hpa at linux.intel.com> CommitDate: Tue, 5 Jan 2016 16:43:50 -0800 [klibc] i386: remove special

The parts of klibc specific to the x86_64 architecture. Signed-off-by: H. Peter Anvin <hpa at zytor.com> --- commit f889dd04bef1aed36ba18161c727af47338e167a tree c25f184d2e3337b52dfe3abd191ec639d4d9543d parent f30fa3db62972125afa68d3b53d03cdb843d3bbd author H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun 2006 16:58:53 -0700 committer H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun

Commit-ID: bc18ea796db39b8d3575948b3d0de28daee38261 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=bc18ea796db39b8d3575948b3d0de28daee38261 Author: H. Peter Anvin <hpa at zytor.com> AuthorDate: Thu, 5 Nov 2015 08:52:33 -0800 Committer: H. Peter Anvin <hpa at zytor.com> CommitDate: Thu, 5 Nov 2015 14:22:01 -0800 [klibc] Inline __arch_libcinit()

Commit-ID: aed6821b52456a4c538c9097999adba451e49248 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=aed6821b52456a4c538c9097999adba451e49248 Author: H. Peter Anvin <hpa at linux.intel.com> AuthorDate: Wed, 9 Apr 2014 16:00:01 -0700 Committer: H. Peter Anvin <hpa at linux.intel.com> CommitDate: Wed, 9 Apr 2014 16:00:01 -0700 [klibc] Move architecture-specific

This is a klibc port to x32 architecture. I tried to reuse as many existing files as possible, hence, a script making symlinks to x86-64 files. I was running this on Debian for about six months and hopefully, found any close to surface bugs. Of course, there are plenty left. Please help with testing. To build you need to run: make ARCH=x32 Makefile | 15 ++--

Commit-ID: c830ba8d7d4f1653b36321c103c02251528e47d6 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=c830ba8d7d4f1653b36321c103c02251528e47d6 Author: H. Peter Anvin <hpa at zytor.com> AuthorDate: Fri, 24 Jan 2014 20:31:26 -0800 Committer: H. Peter Anvin <hpa at zytor.com> CommitDate: Fri, 24 Jan 2014 20:31:26 -0800 [klibc] i386: use the vdso for system calls

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 06/09/2014 02:58 PM, H. Peter Anvin wrote: > > Actually, it looks more like this might be the problem: > > Info: Symbol __muldi3 is defined more than once > Info: Symbol __divdi3 is defined more than once > Info: Symbol __udivmoddi4 is defined more than once > Info: Symbol __ashrdi3 is defined more than once > Info: Symbol dev_stdcon_w is defined more than once >

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

On 06/09/2014 12:14 PM, Ady wrote: > > ... Or, it is being read but some check(sum) fails and thus > discarded. > > If someone wants to catch where the source of the "--once=" problem > is located, I'd guess this is a good starting point. Additionally, > 5.00-pre1 to 5.00-pre7 also failed, so perhaps the correction was > introduced for 5.00-pre8/9 but

Op 2014-06-09 om 15:41 schreef H. Peter Anvin: > On 06/09/2014 02:58 PM, H. Peter Anvin wrote: > > > > Actually, it looks more like this might be the problem: > > > > Info: Symbol __muldi3 is defined more than once > > Info: Symbol __divdi3 is defined more than once > > Info: Symbol __udivmoddi4 is defined more than once > > Info: Symbol __ashrdi3 is

Greetings! As I have presented in the announcement about the ELF dynamic linker preview earlier this week, one of my tasks now is to reduce the size of the root COM32 module to a minimum, and make the rest of the klibc available as dynamic loadable content. After I studied the linker map output and saw what are the minimal requirements of the dynamic linker itself from the C library (the object

The parts of klibc specific to the cris architecture. Signed-off-by: H. Peter Anvin <hpa at zytor.com> --- commit 84f6a72f42cf41e32daa59871a0b5424572093e4 tree 52bad10c1575f773a71cd4f4ea4b8083631f9d82 parent 1eff7c685b36cd0120694fd4150b32a26168d926 author H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun 2006 16:58:18 -0700 committer H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun

The parts of klibc specific to the sparc architecture. Signed-off-by: H. Peter Anvin <hpa at zytor.com> --- commit 1b5c93603ed3460ed1fba9e5d453a6fa54d0ccce tree 7fb0a134b3add408c02b470616d440ad398d86d3 parent 94473ed85b00ec45ff8ee6cac62f60a368ff4534 author H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun 2006 16:58:47 -0700 committer H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun

From: Gene Cumm <gene.cumm at gmail.com> COM32: Add directory functions getcwd(), opendir(), readdir() and closedir(). This depends on the patch that I just submitted creating the COMBOOT API calls. Signed-off-by: Gene Cumm <gene.cumm at gmail.com> --- The intention is to create the library calls with (hopefully) POSIX compliance such that a small application written to use these

From: Gene Cumm <gene.cumm at gmail.com> COM32: Add directory functions getcwd(), opendir(), readdir() and closedir(). This depends on the patch that I just submitted creating the COMBOOT API calls. Signed-off-by: Gene Cumm <gene.cumm at gmail.com> --- The intention is to create the library calls with (hopefully) POSIX compliance such that a small application written to use these

Hi, both https://git.kernel.org/pub/scm/libs/klibc/klibc.git/plain/usr/klibc/arch/i386/libgcc/__ashldi3.S and https://git.kernel.org/pub/scm/libs/klibc/klibc.git/plain/usr/klibc/arch/i386/libgcc/__lshrdi3.S use the following code sequences for shift counts greater 31: 1: 1: xorl %edx,%edx shrl %cl,%edx shl %cl,%eax xorl %eax,%eax

On 8/14/19 9:42 PM, Stefan Kanthak wrote: > Hi, > > both > https://git.kernel.org/pub/scm/libs/klibc/klibc.git/plain/usr/klibc/arch/i386/libgcc/__ashldi3.S > and > https://git.kernel.org/pub/scm/libs/klibc/klibc.git/plain/usr/klibc/arch/i386/libgcc/__lshrdi3.S > use the following code sequences for shift counts greater 31: > > 1: 1: >

From: Matt Fleming <matt.fleming at intel.com> The location of __file_info[] and ansicon_counter are split between the core and ldlinux.c32. We can end up calling __ansicon_close (from fp->oop->close) in the process of reloading ldlinux.c32, and while ansicon_counter is set to its initialised data value of 0 when reloading ldlinux.c32, the core is never reloaded, and so __file_info[]

Hello, I have a bytecode doing 64 bits division and on Mingw32/x86, lli complains it cannot resolve __udivdi3 when running it. Those symbols are all part of libgcc and all present in lli, but they cannot be found by SearchForAddressOfSymbol (not in any DLL). To workaround that, I explicitely define them in Win32/DynamicLibrary.inc if the current target is Mingw32 (patch attached). Anybody had