similar to: [klibc:master] x86_64: Reduce ld max-page-size option again

Building klibc with binutils 2.30 results in the following layout for klibc.so: Idx Name Size VMA LMA File off Algn 0 .text 0000d1ff 0000000000200200 0000000000200200 00000200 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .rodata 000031af 0000000000300000 0000000000300000 00100000 2**5

Commit-ID: 2a705525e0816f9d708d7c41688f6bcb127374fe Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=2a705525e0816f9d708d7c41688f6bcb127374fe Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Sat, 5 Jan 2019 20:59:33 +0000 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Fri, 18 Jan 2019 03:10:14 +0000 [klibc] x86_64: Use -Ttext-segment

Building klibc for x86_64 with binutils 2.31 adds an extra .note.gnu.property section to klibc.so, the address of which is not affected by the -Ttext option. Loading a klibc executable then fails with the following kernel log message: 9409 (sh.shared): Uhuuh, elf segment at 0000000000200000 requested but the memory is mapped already I don't exactly see why this is happening, but it is

The *.shared targets require -shared on powerpc, and -R leads to linker errors. This patch makes the -R an arch define. ia64 at least requires -R. --- ash/Makefile +++ ash/Makefile 2003/11/27 15:04:02 @@ -36,7 +36,7 @@ $(STRIP) $(PROG) $(PROG).shared: $(OBJS) $(LIBS) - $(LD) $(LDFLAGS) -o $(PROG).shared -e main $(KLIBSRC)/interp.o $(OBJS) -R $(KLIBSRC)/libc.so $(LIBGCC) + $(LD) $(LDFLAGS)

Commit-ID: 72d6d78a8f0d24a64911c246487402c81b4beb9d Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=72d6d78a8f0d24a64911c246487402c81b4beb9d Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Sun, 20 Jan 2019 19:41:47 +0000 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sun, 20 Jan 2019 21:15:17 +0000 [klibc] Use -Ttext-segment to link

Commit-ID: 6eb77ce795189d39fc0f7bc12eb8d7be11e46718 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=6eb77ce795189d39fc0f7bc12eb8d7be11e46718 Author: H. Peter Anvin <hpa at linux.intel.com> AuthorDate: Tue, 15 Apr 2014 13:29:30 -0700 Committer: H. Peter Anvin <hpa at linux.intel.com> CommitDate: Tue, 15 Apr 2014 13:29:30 -0700 [klibc] x86-64: disable the use

Commit-ID: ad72c27485b86171153ab26a1c1035f8e9bbd5e3 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=ad72c27485b86171153ab26a1c1035f8e9bbd5e3 Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Sun, 6 Jan 2019 20:50:56 +0000 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Fri, 18 Jan 2019 03:10:14 +0000 [klibc] Kbuild: Remove

It seems that a minor modification to usr/klibc/arch/$(ARCH)/MCONFIG is needed to build klibc successfully against kernel version 3.4.3. At lease the arch "arm" and "x86_64" have this issue. It is because that some include files are under "generated/asm/" in addition to "asm/". --- a/usr/klibc/arch/x86_64/MCONFIG +++ b/usr/klibc/arch/x86_64/MCONFIG @@ -36,4

In the v3.6 kernel, many of the headers were split out into a uapi variant. klibc should be using those variants to compile. There is also a generated subdir, to seperate out generated headers. The old kernel header location needs to be included as well, because linux/compiler.h is available only in the base include directory. Signed-off-by: Robin H. Johnson <robbat2 at gentoo.org> ---

On Fri, Dec 30, 2016 at 01:34:15AM +0800, kernel test robot wrote: > > FYI, we noticed the following commit: > > commit: 0c5a9920fbb514bd4098e2fb6340d3274bf2bca7 ("lib: add linker tables test driver") > https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git 20161216-linker-tables-v5 > > in testcase: trinity > with following parameters: > >

Hi Andreas, On Mon, May 18, 2020 at 9:56 AM Andreas Schwab <schwab at linux-m68k.org> wrote: > > On Mai 18 2020, Michael Ellerman wrote: > > > The old drivers may be crufty but they presumably have been tested by > > people and at least somewhat work. > > I can confirm that the nvidia fbdev driver is working perfectly fine. > > > I gave it a quick spin on

The parts of klibc specific to the sh architecture. Signed-off-by: H. Peter Anvin <hpa at zytor.com> --- commit 94473ed85b00ec45ff8ee6cac62f60a368ff4534 tree 5c09fdd824962cba83c198ac1dd077045d2cb0b1 parent 418ab99cc64fed344e2d3e446208f48655cccb31 author H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun 2006 16:58:44 -0700 committer H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun 2006

Hi, Can anybody advise me how to debug this crash? it happens when I try to start a 32 bit kernel on my 64 bit Xen system, the kernel is my own using opensuse 11.1 rc1 2.6.27.7 xen patches, the kernel works as 32 and 64 bit dom0, and as 64 bit domU PV, is there a technique to find out where in the kernel source the crash happens? i.e what line in the source code? (XEN) mm.c:707:d49 Error getting

Commit-ID: f1c1f4f99e60ac0f855a0582b4aebebfbb0804dc Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=f1c1f4f99e60ac0f855a0582b4aebebfbb0804dc Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Tue, 17 Jul 2018 02:55:19 +0100 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Fri, 18 Jan 2019 03:10:14 +0000 [klibc] Add RISC-V (RV64) port

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 ++--

hi. i've got a clustered mail system with glusterfs and some postfix, squirrelmail and dovecot machines sharing the same storage system through glusterfs. each server has only postfix or squirrel or dovecot installed on it. The thing is... dovecot servers hang very often and the last thing they always log is this: ************* login: Unable to handle kernel paging request at

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

hello hpa, here my birthday submission :) please pull: git pull git://git.debian.org/users/maks/klibc.git maks Sam fixed a longstanding x86_32 build bug, thus it seems a good time to flush the queue of the piled up patches, the shortlog tells it: Aurelien Jarno (1): [klibc] sh4: syscalls fixes Benjamin Cama (1): [klibc] fstype: btrfs size endianness fix Mike Waychison (2):

Hello, I've build drm and nouveau from git and got this error while starting Xorg. Another thing is that before the install instructions on the wiki worked I had to install xorg-dev. This was the error I got before installing xorg-dev: ./configure: line 20257: syntax error near unexpected token `RANDR,' ./configure: line 20257: `XORG_DRIVER_CHECK_EXT(RANDR, randrproto)' I'm not

We currently use KLIBCKERNELSRC and KLIBCKERNELOBJ variables which used to be required to point to a kernel source and object directories. However the kernel headers were reorganised starting in Linux 3.7 such that that doesn't work properly. This series removes KLIBCKERNELOBJ and changes the use and documentation of KLIBCKERNELSRC to be consistent. Ben. Ben Hutchings (4): [klibc]