search for: klibcsharedflags

...arch/alpha/MCONFIG index e7dc61a..ad11372 100644 --- a/usr/klibc/arch/alpha/MCONFIG +++ b/usr/klibc/arch/alpha/MCONFIG @@ -13,4 +13,4 @@ KLIBCBITSIZE = 64 # calls, and work on the memory models for this architecture # 7 GB - normal binaries start at 4.5 GB, and the stack is below # the binary. -KLIBCSHAREDFLAGS = -Ttext 0x1c0000200 +KLIBCSHAREDFLAGS = -Ttext-segment 0x1c0000000 diff --git a/usr/klibc/arch/arm/MCONFIG b/usr/klibc/arch/arm/MCONFIG index 53bc1dc..8a7096b 100644 --- a/usr/klibc/arch/arm/MCONFIG +++ b/usr/klibc/arch/arm/MCONFIG @@ -21,12 +21,12 @@ KLIBCREQFLAGS += -mthumb KLIBCLDFLAGS += --t...

...mit;h=47e429ec6c758b98a00e69df541448942c6f3ba3 Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Sat, 19 Jan 2019 22:47:18 +0000 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 19 Jan 2019 22:51:00 +0000 [klibc] Build and install shared binaries only if KLIBCSHAREDFLAGS is defined The shared library build has never worked on ia64, and Debian has a longstanding patch that changes the install targets to install static binaries for ia64. This can be generalised to checking whether KLIBCSHAREDFLAGS is defined, as without that we can't expect to build a working s...

.../MCONFIG index ad11372f9266..be56a0d52d4c 100644 --- a/usr/klibc/arch/alpha/MCONFIG +++ b/usr/klibc/arch/alpha/MCONFIG @@ -13,4 +13,4 @@ KLIBCBITSIZE = 64 # calls, and work on the memory models for this architecture # 7 GB - normal binaries start at 4.5 GB, and the stack is below # the binary. -KLIBCSHAREDFLAGS = -Ttext-segment 0x1c0000000 +KLIBCSHAREDFLAGS = $(IMAGE_BASE) 0x1c0000000 diff --git a/usr/klibc/arch/arm/MCONFIG b/usr/klibc/arch/arm/MCONFIG index 8a7096b8cced..34a3305da878 100644 --- a/usr/klibc/arch/arm/MCONFIG +++ b/usr/klibc/arch/arm/MCONFIG @@ -21,12 +21,12 @@ KLIBCREQFLAGS += -mthumb KLI...

...0f0..baa7e59854f8 100644 --- a/usr/klibc/arch/i386/MCONFIG +++ b/usr/klibc/arch/i386/MCONFIG @@ -30,4 +30,4 @@ KLIBCBITSIZE = 32 # This address needs to be reachable using normal inter-module # calls, and work on the memory models for this architecture # 96 MB - normal binaries start at 128 MB -KLIBCSHAREDFLAGS = -Ttext-segment 0x06000000 +KLIBCSHAREDFLAGS = $(IMAGE_BASE) 0x06000000 diff --git a/usr/klibc/arch/mips64/MCONFIG b/usr/klibc/arch/mips64/MCONFIG index 6a4b41b2f85c..3d7f20da08be 100644 --- a/usr/klibc/arch/mips64/MCONFIG +++ b/usr/klibc/arch/mips64/MCONFIG @@ -20,4 +20,4 @@ KLIBCBITSIZE = 64 #...

...7d3fccd..e6f50dde 100644 --- a/usr/klibc/arch/i386/MCONFIG +++ b/usr/klibc/arch/i386/MCONFIG @@ -30,7 +30,7 @@ KLIBCBITSIZE = 32 # This address needs to be reachable using normal inter-module # calls, and work on the memory models for this architecture # 96 MB - normal binaries start at 128 MB -KLIBCSHAREDFLAGS = -Ttext-segment 0x06000000 +KLIBCSHAREDFLAGS = $(LD_IMAGE_BASE_OPT) 0x06000000 # Kernel uses dedicated page or vDSO for signal return since 2.5.55 KLIBCEXECSTACK := n diff --git a/usr/klibc/arch/mips64/MCONFIG b/usr/klibc/arch/mips64/MCONFIG index 94b825a6..6dcb143e 100644 --- a/usr/klibc/arch...

...0f0..baa7e59854f8 100644 --- a/usr/klibc/arch/i386/MCONFIG +++ b/usr/klibc/arch/i386/MCONFIG @@ -30,4 +30,4 @@ KLIBCBITSIZE = 32 # This address needs to be reachable using normal inter-module # calls, and work on the memory models for this architecture # 96 MB - normal binaries start at 128 MB -KLIBCSHAREDFLAGS = -Ttext-segment 0x06000000 +KLIBCSHAREDFLAGS = $(IMAGE_BASE) 0x06000000 diff --git a/usr/klibc/arch/mips64/MCONFIG b/usr/klibc/arch/mips64/MCONFIG index 6a4b41b2f85c..3d7f20da08be 100644 --- a/usr/klibc/arch/mips64/MCONFIG +++ b/usr/klibc/arch/mips64/MCONFIG @@ -20,4 +20,4 @@ KLIBCBITSIZE = 64 #...

...s(+) diff --git a/usr/klibc/arch/alpha/MCONFIG b/usr/klibc/arch/alpha/MCONFIG index ad11372f..072adb85 100644 --- a/usr/klibc/arch/alpha/MCONFIG +++ b/usr/klibc/arch/alpha/MCONFIG @@ -14,3 +14,7 @@ KLIBCBITSIZE = 64 # 7 GB - normal binaries start at 4.5 GB, and the stack is below # the binary. KLIBCSHAREDFLAGS = -Ttext-segment 0x1c0000000 + +# Kernel uses stack trampoline for signal return unless we set +# sa_restorer +KLIBCEXECSTACK := y diff --git a/usr/klibc/arch/arm/MCONFIG b/usr/klibc/arch/arm/MCONFIG index 8a7096b8..ae407cb9 100644 --- a/usr/klibc/arch/arm/MCONFIG +++ b/usr/klibc/arch/arm/MCONFIG @...

This reverts commit 9d8d648e604026b32cad00a84ed6c29cbd157641, which broke signal handing on some architectures. On m68k and parisc, signal return depends on a trampoline that the kernel writes on the stack. On alpha, s390, and sparc (32-bit), we can avoid this by providing our own function as sa_restorer, but we currently don't. Signed-off-by: Ben Hutchings <ben at decadent.org.uk>

On Sat, 2020-07-25 at 15:16 -0700, Bill Wendling wrote: > On Sat, Jul 25, 2020 at 2:56 PM Ben Hutchings <ben at decadent.org.uk> wrote: > > On Sat, 2020-07-25 at 14:36 -0700, Bill Wendling wrote: > > [...] > > > I upstreamed a few patches to klibc to fix a few linker errors. Some > > > of these might help: > > > > I applied v3 of your patch

while this doesn't fix the problem that shared doesn't work there, it at least ensures that klibc.so and (e.g.) sh.shared do not try to occupy the same virtual addresses mips64 is also missing KLIBCSHAREDFLAGS and needs treatment Signed-off-by: Thorsten Glaser <tg at mirbsd.org> --- usr/klibc/arch/ia64/MCONFIG | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/usr/klibc/arch/ia64/MCONFIG b/usr/klibc/arch/ia64/MCONFIG index ad868ef..5b2eac6 100644 --- a/usr/klibc/arch/ia64/MCONFIG +...

This is a series of patches for clang compatibility: - Using flags needed flags and removing unsupported flags. - Adding support for clang's LLD linker. - Removing a variety of warnings. Bill Wendling (3): [klibc] Kbuild: use "libc.a" with clang [klibc] Kbuild: Add "-fcommon" for clang builds [klibc] Clean up clang warnings Michael Davidson (1): [klibc] Kbuild:

Dear experts, I'm new in klibc and currently studying the source codes. I'm looking at the codes in usr/klibc/arch and can't figure out why does, e.g. in x86_64, the text segment offset differ from system v x86_64 abi (which is 4 Mb)? How does this value was calculated? Thanks in advance! Nikita.

On 11/23/18 8:09 AM, eno wrote: > Dear experts, > > I'm new in klibc and currently studying the source codes. > I'm looking at the codes in usr/klibc/arch and can't figure out why > does, e.g. in x86_64, the text segment offset differ from system v > x86_64 abi (which is 4 Mb)? How does this value was calculated? > > Thanks in advance! > Nikita. It is set

- Renamed IMAGE_BASE to LD_IMAGE_BASE_OPT. - Moved "-fcommon" to KLIBCREQFLAGS in scripts/Kbuild.klibc. - Remove "dash" warning fixes which have been upstreamed. - Conditionalize the inclusion of compiler flags by using the proper compiler name or "cc-option". - Added "-Werror" to "cc-option" to catch flags that cause warnings. - Retain

.../usr/klibc/arch/i386/MCONFIG b/usr/klibc/arch/i386/MCONFIG index bfec004..0704669 100644 --- a/usr/klibc/arch/i386/MCONFIG +++ b/usr/klibc/arch/i386/MCONFIG @@ -31,6 +31,3 @@ KLIBCBITSIZE = 32 # calls, and work on the memory models for this architecture # 96 MB - normal binaries start at 128 MB KLIBCSHAREDFLAGS = -Ttext-segment 0x06000000 - -# Asm includes for i386 are in the merged x86 tree -KLIBCARCHINCFLAGS = -I$(KLIBCKERNELOBJ)/arch/x86/include diff --git a/usr/klibc/arch/ppc/MCONFIG b/usr/klibc/arch/ppc/MCONFIG index 6630df7..46c5923 100644 --- a/usr/klibc/arch/ppc/MCONFIG +++ b/usr/klibc/arch/ppc/MC...

...-I$(KLIBCKERNELOBJ)/include -I$(srctree)/include) \ $(KLIBCARCHINCFLAGS) diff --git a/usr/klibc/arch/i386/MCONFIG b/usr/klibc/arch/i386/MCONFIG index 1150ece..eb7a5e9 100644 --- a/usr/klibc/arch/i386/MCONFIG +++ b/usr/klibc/arch/i386/MCONFIG @@ -33,4 +33,7 @@ KLIBCBITSIZE = 32 KLIBCSHAREDFLAGS = -Ttext 0x06000200 # Asm includes for i386 are in the merged x86 tree -KLIBCARCHINCFLAGS = -I$(KLIBCKERNELOBJ)/arch/x86/include +KLIBCARCHINCFLAGS = -I$(KLIBCKERNELOBJ)/arch/x86/include/uapi \ + -I$(KLIBCKERNELOBJ)/arch/x86/include/generated/uapi \ + -I$(KL...

...ode at 0x400000. Seems that the increased maximum page size is just for better performance, and the value can be decreased without losing compatibility. New ld versions have an option for this: -z max-page-size=SIZE Set maximum page size to SIZE Adding "-z max-page-size=0x100000" to KLIBCSHAREDFLAGS fixes klibc.so build on new binutils - the resulting binaries run fine even on kernels with the exec-shield patch. Probably this option can even be added unconditionally - GNU ld silently ignores all "-z KEYWORD" options which it does not understand, therefore the added options should no...

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]

...# 2 MB - normal binaries start at 4 MB # -# Recent binutils use max-page-size=0x200000 by default, which pushes +# binutils now uses max-page-size=0x200000 by default, which pushes # klibc.so data over the 4 MB mark, overlapping the executable. -# Revert to the old max-page-size=0x100000 value. -KLIBCSHAREDFLAGS = -Ttext 0x00200200 -z max-page-size=0x100000 +# The old default was max-page-size=0x100000, but that also results +# in a broken layout with binutils 2.30. Since there's no +# architectural page size betwen 4 KB and 2MB, set it to 4 KB. +KLIBCSHAREDFLAGS = -Ttext 0x00200200 -z max-pag...

...86_64/MCONFIG +++ b/usr/klibc/arch/x86_64/MCONFIG @@ -35,7 +35,7 @@ KLIBCLDFLAGS = -m elf_x86_64 # The old default was max-page-size=0x100000, but that also results # in a broken layout with binutils 2.30. Since there's no # architectural page size betwen 4 KB and 2MB, set it to 4 KB. -KLIBCSHAREDFLAGS = -Ttext 0x00200200 -z max-page-size=0x1000 +KLIBCSHAREDFLAGS = -Ttext-segment 0x00200000 -z max-page-size=0x1000 # Asm includes for x86_64 are in the merged x86 tree KLIBCARCHINCFLAGS = -I$(KLIBCKERNELOBJ)/arch/x86/include -------------- next part -------------- A non-text attachment w...