Define MMAP2_PAGE_SHIFT to -1 for microblaze so the correct shift
for the syscall is determined dynamically using getpagesize
ports/ChangeLog.microblaze
2014-02-04 David Holsgrove <david.holsgrove@xilinx.com>
* sysdeps/unix/sysv/linux/microblaze/mmap64.c: New file.
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
ARMv4 does not have the blx instruction, so use the BLX macro which
handles abstracting this for us.
Build tested for armv7, armv4t and armv4.
ports/ChangeLog.arm:
2014-01-24 Will Newton <will.newton@linaro.org>
[BZ #16499]
* sysdeps/unix/sysv/linux/arm/clone.S: Use BLX macro instead
of blx instruction directly.
The frame pointer register is rarely used for that purpose on ARM and
applications that look at the contents of the jmp_buf may be relying
on reading an unencrypted value. For example, Ruby uses the contents
of jmp_buf to find the root set for garbage collection so relies on
this pointer value being unencrypted. Without this patch the Ruby
testsuite fails with a segmentation fault.
ports/ChangeLog.arm:
2013-01-14 Will Newton <will.newton@linaro.org>
* sysdeps/arm/__longjmp.S: Don't apply pointer encryption
to fp register.
* sysdeps/arm/setjmp.S: Likewise.
* sysdeps/arm/include/bits/setjmp.h (JMP_BUF_REGLIST): Add
fp to register list, remove a4.
* sysdeps/unix/sysv/linux/arm/sysdep.h (PTR_MANGLE_LOAD):
New macro.
Examining MIPS test results showed an ABI test failure that I must
have missed in 2.18 testing: hard-float and soft-float o32 no longer
have the same set of symbols (because of the __mips_fpu_getcw and
__mips_fpu_setcw functions, present for hard-float only, used by
fpu_control.h for hard-float MIPS16) and so need separate ABI test
baselines (they always were ABI-incompatible - the function-calling
interface is different - but previously had the same set of symbols
and versions so didn't need separate baselines).
Tested for hard-float and soft-float o32.
* sysdeps/unix/sysv/linux/mips/mips32/nptl/libc.abilist: Move to
....
* sysdeps/unix/sysv/linux/mips/mips32/fpu/nptl/libc.abilist:
... here.
* sysdeps/unix/sysv/linux/mips/mips32/nofpu/nptl/libc.abilist: New
file.
This addresses a long standing collision between userspace headers and
kernel headers only on ia64 systems. All other types have a __ prefix
in the ptrace headers except these two. Let's finally namespace these.
Verified that at least strace still builds after this change, as well
as after deleting all the struct hacks it has specifically for ia64.
URL: https://sourceware.org/bugzilla/show_bug.cgi?id=762
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
All the other ptrace structures in this file have a __ prefix except this
new one. This in turn causes build problems for most packages that try to
use ptrace such as strace:
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../linux/x86_64 -I../../linux \
-I./linux -Wall -Wwrite-strings -g -O2 -MT process.o -MD -MP \
-MF .deps/process.Tpo -c -o process.o ../../process.c
In file included from ../../process.c:63:0:
/usr/include/linux/ptrace.h:58:8: error: redefinition of 'struct ptrace_peeksiginfo_args'
struct ptrace_peeksiginfo_args {
^
In file included from ../../defs.h:159:0,
from ../../process.c:37:
/usr/include/sys/ptrace.h:191:8: note: originally defined here
struct ptrace_peeksiginfo_args
^
Since this struct was introduced in glibc-2.18, there shouldn't be any
real regressions with adding the __ prefix.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The sp check has to be moved up to the start of the func since it now
makes a system call and that'll clobber a lot of registers.
URL: https://sourceware.org/bugzilla/show_bug.cgi?id=16372
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The new tst-setjmp-fp test has been failing on IA64 because the setjmp
and longjmp helpers take care of saving/restoring the fpsr register.
Per the C standards, this is incorrect, so disable that logic.
URL: https://sourceware.org/bugzilla/show_bug.cgi?id=16379
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This file has a few #if 0 code paths which cause a build time warning:
ports/sysdeps/unix/sysv/linux/ia64/ioperm.c:66:7: warning:
variable 'prot' set but not used [-Wunused-but-set-variable]
Rather than add more #if 0 around that variable, just delete the code
altogether. Not like it's going to ever be implemented.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Fix the RLIM64_INFINITY constant for O32 and N32 ABIs to match the
kernel one. Change the getrlimit64/setrlimit64 into old compat symbols,
and provide the Linux generic getrlimit64/setrlimit64 functions as
GLIBC_2_19 version.
RLIM64_INFINITY was supposed to be a glibc convention rather than
anything seen by the kernel, but it ended being passed to the kernel
through the prlimit64 syscall. On O32 and N32 ABIs, we therefore
end-up with different values on the userland and kernel side:
* On the kernel side, the value is defined for all architectures as
include/uapi/linux/resource.h:
#define RLIM64_INFINITY (~0ULL)
* On the GNU libc side, the value is defined in
ports/sysdeps/unix/sysv/linux/mips/bits/resource.h:
For the O32 and N32 ABI:
# define RLIM64_INFINITY 0x7fffffffffffffffULL
and for the N64 ABI:
# define RLIM64_INFINITY 0xffffffffffffffffUL
This was not a problem until the prlimit64 syscall was wired in the
2.6.36 kernel. Given the GLIBC uses the prlimit64 syscall to implement
getrlimit64 and setrlimit64, pam_limits.so is setting the limits to
a very big value instead of infinity. As a normal user process can
later only decrease the value and not increase it, it will later get
and EPERM error when trying to set the value to infinity with setrlimit.
The GLIBC has this constant for more than 7 years, and as it is defined
in a header file, it means a lot of binaries are in the wild. This patch
fixes that by adding a wrapper to fix the value passed to or received
from the kernel, before or after calling the prlimit64 syscall.
The hard alignment of 8 was appropriate for most platforms for
which 8-byte values are 8-byte aligned, but this is not true
for the nios2 platform, so only align to the alignment of the
8-byte type on the platform.
Remove the explicit alignment of struct statfs as it's redundant.
Autoconf has been deprecating configure.in for quite a long time.
Rename all our configure.in and preconfigure.in files to .ac.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Convert __longjmp code to allow building as Thumb.
ports/ChangeLog.arm:
2013-10-04 Will Newton <will.newton@linaro.org>
* sysdeps/arm/__longjmp.S (NO_THUMB): Remove define.
(__longjmp): Use Thumb supported instructions.
* sysdeps/unix/sysv/linux/arm/____longjmp_chk.S (NO_THUMB):
Remove define.
Add support for pointer encryption in glibc internal structures in C
and assembler code. Pointer encryption is a glibc security feature
described here:
https://sourceware.org/glibc/wiki/PointerEncryption
The ARM implementation uses global variables instead of thread pointer
relative accesses to get the value of the pointer encryption guard
because accessing the thread pointer can be very expensive on older
ARM cores.
ports/ChangeLog.arm:
2013-10-03 Will Newton <will.newton@linaro.org>
* sysdeps/arm/__longjmp.S (__longjmp): Demangle fp, sp
and lr when restoring register values.
* sysdeps/arm/include/bits/setjmp.h (JMP_BUF_REGLIST): Remove
sp and lr from list and replace fp with a4.
* sysdeps/arm/jmpbuf-unwind.h (_jmpbuf_sp): New function.
(_JMPBUF_UNWINDS_ADJ): Call _jmpbuf_sp.
* sysdeps/arm/setjmp.S (__sigsetjmp): Mangle fp, sp and lr
before storing register values.
* sysdeps/arm/sysdep.h (LDST_GLOBAL): New macro.
* sysdeps/unix/sysv/linux/arm/sysdep.h (PTR_MANGLE): New macro.
(PTR_DEMANGLE): Likewise. (PTR_MANGLE2): Likewise.
(PTR_DEMANGLE2): Likewise.
It has been a long practice for software using IEEE 754 floating-point
arithmetic run on MIPS processors to use an encoding of Not-a-Number
(NaN) data different to one used by software run on other processors.
And as of IEEE 754-2008 revision [1] this encoding does not follow one
recommended in the standard, as specified in section 6.2.1, where it
is stated that quiet NaNs should have the first bit (d1) of their
significand set to 1 while signalling NaNs should have that bit set to
0, but MIPS software interprets the two bits in the opposite manner.
As from revision 3.50 [2][3] the MIPS Architecture provides for
processors that support the IEEE 754-2008 preferred NaN encoding format.
As the two formats (further referred to as "legacy NaN" and "2008 NaN")
are incompatible to each other, tools have to provide support for the
two formats to help people avoid using incompatible binary modules.
The change is comprised of two functional groups of features, both of
which are required for correct support.
1. Dynamic linker support.
To enforce the NaN encoding requirement in dynamic linking a new ELF
file header flag has been defined. This flag is set for 2008-NaN
shared modules and executables and clear for legacy-NaN ones. The
dynamic linker silently ignores any incompatible modules it
encounters in dependency processing.
To avoid unnecessary processing of incompatible modules in the
presence of a shared module cache, a set of new cache flags has been
defined to mark 2008-NaN modules for the three ABIs supported.
Changes to sysdeps/unix/sysv/linux/mips/readelflib.c have been made
following an earlier code quality suggestion made here:
http://sourceware.org/ml/libc-ports/2009-03/msg00036.html
and are therefore a little bit more extensive than the minimum
required.
Finally a new name has been defined for the dynamic linker so that
2008-NaN and legacy-NaN binaries can coexist on a single system that
supports dual-mode operation and that a legacy dynamic linker that
does not support verifying the 2008-NaN ELF file header flag is not
chosen to interpret a 2008-NaN binary by accident.
2. Floating environment support.
IEEE 754-2008 features are controlled in the Floating-Point Control
and Status (FCSR) register and updates are needed to floating
environment support so that the 2008-NaN flag is set correctly and
the kernel default, inferred from the 2008-NaN ELF file header flag
at the time an executable is loaded, respected.
As the NaN encoding format is a property of GCC code generation that is
both a user-selected GCC configuration default and can be overridden
with GCC options, code that needs to know what NaN encoding standard it
has been configured for checks for the __mips_nan2008 macro that is
defined internally by GCC whenever the 2008-NaN mode has been selected.
This mode is determined at the glibc configuration time and therefore a
few consistency checks have been added to catch cases where compilation
flags have been overridden by the user.
The 2008 NaN set of features relies on kernel support as the in-kernel
floating-point emulator needs to be aware of the NaN encoding used even
on hard-float processors and configure the FPU context according to the
value of the 2008 NaN ELF file header flag of the executable being
started. As at this time work on kernel support is still in progress
and the relevant changes have not made their way yet to linux.org master
repository.
Therefore the minimum version supported has been artificially set to
10.0.0 so that 2008-NaN code is not accidentally run on a Linux kernel
that does not suppport it. It is anticipated that the version is
adjusted later on to the actual initial linux.org kernel version to
support this feature. Legacy NaN encoding support is unaffected, older
kernel versions remain supported.
[1] "IEEE Standard for Floating-Point Arithmetic", IEEE Computer
Society, IEEE Std 754-2008, 29 August 2008
[2] "MIPS Architecture For Programmers, Volume I-A: Introduction to the
MIPS32 Architecture", MIPS Technologies, Inc., Document Number:
MD00082, Revision 3.50, September 20, 2012
[3] "MIPS Architecture For Programmers, Volume I-A: Introduction to the
MIPS64 Architecture", MIPS Technologies, Inc., Document Number:
MD00083, Revision 3.50, September 20, 2012
Another example of all the 64bit arches getting the definition via a
common file, but the 32bit ones all adding it by themselves and hppa
was missed.
I'm not entirely sure about the usage of GLIBC_2.19 symbols here.
We'd like to backport this so people can use it, but it means we'd
be releasing a glibc-2.17/glibc-2.18 with a GLIBC_2.19 symbol in it.
But maybe it won't be a big deal since you'd only get that 2.19 ref
if you actually used the symbol ?
There hasn't been a glibc release where hppa worked w/out a bunch of
patches, so in reality there's only two distros that matter -- Gentoo
and Debian.
Reported-by: Jeroen Roovers <jer@gentoo.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The mov lr, pc instruction will lose the Thumb bit from the return address
so use blx lr instead.
ports/ChangeLog.arm:
2013-08-30 Will Newton <will.newton@linaro.org>
[BZ #15909]
* sysdeps/unix/sysv/linux/arm/clone.S (__clone): Use blx
instead of mov lr, pc.
