C2011 officially includes an 'anonymous union' feature, and GCC has
supported it for many years. It makes sub-fields of a union that's a
struct field appear to be fields of the parent struct. If we use this
in the definition of siginfo_t, we don't need to define lots of
innocuous-looking identifiers like 'si_pid' as macros expanding to
chains of field accessors. The catch, however, is that the compiler
used to compile *programs that use glibc* - not just glibc itself -
must accept the use of this feature (in system headers) even when
running in an older conformance mode.
This patch only touches siginfo_t, but if people like the idea, we
could also do it for several other types:
and maybe also - these use names in the user namespace for the fields
that would be removed:
net/if.h (ifaddr)
ifaddrs.h (ifaddrs)
netinet/in6.h (ip6_hdr) (really should be bitfields instead)
netinet/icmp6.h (many)
net/if_ppp.h (ifpppstatsreq, ifpppcstatsreq)
net/if_shaper.h (shaperconf)
a.out.h (exec) (only some versions)
sys/quota.h (dqblk?) (the dq_* macros refer to a field that doesn't exist?!)
There are still more hits in sunrpc and nis, but since hopefully that
code is going to go away, I don't propose to mess with them. And
there may be even more that aren't caught by grepping for
'#define IDENT IDENT.IDENT'.
As a side note (and this could be split for commit if felt
appropriate), the siginfo_t field aliases 'si_int' and 'si_ptr' are
not in POSIX. There are a few uses of these within glibc itself, and
a handful more in third-party software (not glibc, not uclibc, and not
linux) so I have preserved them, but put them under __USE_MISC and
added a deprecation warning.
This passes the glibc testsuite on x86-64-linux, which probably
*doesn't* test the case where someone is compiling a program in
an older conformance mode that uses siginfo_t
(-std=c99 -D_XOPEN_SOURCE=600, perhaps).
What do you think?
zw
* sysdeps/unix/sysv/linux/bits/types/siginfo_t.h (siginfo_t):
Use C2011 anonymous union and anonymous struct-in-union features
to define this type. Rename some public fields with their
official names.
(si_pid, si_uid, si_timerid, si_overrun, si_status, si_utime)
(si_stime, si_value, si_addr, si_addr_lsb, si_lower, si_upper)
(si_pkey, si_band, si_fd, si_call_addr, si_syscall, si_arch):
Do not define as macros.
(si_int, si_ptr): Define only when __USE_MISC, with deprecation
warnings.
* sysdeps/unix/sysv/linux/ia64/bits/siginfo-arch.h
* sysdeps/unix/sysv/linux/sparc/bits/siginfo-arch.h
* sysdeps/unix/sysv/linux/tile/bits/siginfo-arch.h
(__SI_SIGFAULT_ADDL): Define all fields with their public names
when __USE_GNU, or with impl-namespace names otherwise.
(si_imm, si_segvflags, si_isr, si_trapno): Do not define as macros.
* sysdeps/unix/sysv/linux/timer_routines.c (timer_helper_thread)
Use si_value.sival_ptr instead of si_ptr.
* sysdeps/unix/sysv/linux/tst-getpid1.c (do_test):
Use si_value.sival_int instead of si_int.
Fix remaining return type of ifunc resolver declaration
Since Martin Sebor's commit
commit ee4e992ebe5f9712faedeefe8958b67d61eaa0f2
Author: Martin Sebor <email address hidden>
Date: Tue Aug 22 09:35:23 2017 -0600
Declare ifunc resolver to return a pointer to the same type as the target
function to help GCC detect incompatibilities between the two when it's
enhanced to do so.
builds for powerpc64le fail in the declaration of some ifunc resolvers,
because the ifunc is declared with unmatching return types. One of the
declarations comes from the __ifunc_resolver macro, which was patched by
the aforementioned commit:
/* Helper / base macros for indirect function symbols. */
#define __ifunc_resolver(type_name, name, expr, arg, init, classifier) \
classifier inhibit_stack_protector \
__typeof (type_name) *name##_ifunc (arg) \
whereas the other comes from the unpatched __ifunc macro when
HAVE_GCC_IFUNC is not defined:
This patch changes the return type of the ifunc resolver in the __ifunc
macro, so that it matches the return type of the target function,
similarly to what the aforementioned commit does.
Tested for powerpc64le and s390x with unpatched GCC.
* include/libc-symbols.h: [!defined HAVE_GCC_IFUNC] (__ifunc):
Change the return type of the ifunc resolver to match the return
type of the target function.
78ca091...
by
Adhemerval Zanella <email address hidden>
Fix {INLINE,INTERNAL}_SYSCALL macros for x32
The problem for x32 is the {INTERNAL,INLINE}_SYSCALL C macros explicit
cast the arguments to 'long int', thus passing as 32 bits arguments
that should be passed to 64 bits.
Previous x32 implementation uses the auto-generated syscalls from
assembly macros (syscalls.list), so the {INTERNAL,INLINE}_SYSCALL
macros are never used with 64 bit argument in x32 (which are
internally broken for this ILP).
To fix it I used a strategy similar to MIPS64n32 (although both
ABI differs for some syscalls on how top pass 64-bits arguments)
where argument types for kernel call are defined using GCC extension
'typeof' with a arithmetic operation. This allows 64-bits arguments
to be defined while 32-bits argument will still passed as 32-bits.
I also cleanup the {INLINE,INTERNAL}_SYSCALL definition by defining
'inline_syscallX' instead of constructing the argument passing using
macros (it adds some readability) and removed the ununsed
INTERNAL_SYSCALL_NCS_TYPES define (since the patch idea is exactly to
avoid requiric explicit types passing).
Remove duplicate inclusion of header math-svid-compat.h
The header math-svid-compat.h has been unintentionally included twice in
the wrappers for the remainder functions. This patch removes the
duplicate inclusions.
During the development of float128 on powerpc64le, the ulps have been
generated since early versions of the patches. On those versions, the
functions gamma and pow10 were mistakenly thought to be part of the API.
After review, the functions were removed, however the ulps for them were
carried in the ulps file.
This patch removes such entries from the ulps file, as well as it
shrinks the ulps for the cpow and lgamma functions.
Fix tgmath.h handling of complex integers (bug 21684).
The tgmath.h macros return a real type not a complex type when an
argument is of complex integer type (a GNU extension) and there are no
arguments of complex floating type. It seems clear that just as real
integers are mapped to double for tgmath.h, so complex integers should
be mapped to _Complex double.
This patch implements such a mapping. The main complication in fixing
this bug is that the tgmath.h macros expand their arguments a large
number of times, resulting in exponential blowup of the size of the
expansion when calls to tgmath.h macros are used in the arguments of
such macros; it would be unfortunate for fixing a bug with a fairly
obscure extension to make the macros expand their arguments even more
times. Thus, this patch optimizes the definitions of the relevant
macros. __tgmath_real_type previously expanded its argument 7 times
and now expands it 3 times. __tgmath_complex_type, used in place of
__tgmath_real_type only for functions that might return either real or
complex types, not for complex functions that always return real types
or always return complex types, expands its argument 5 times. So the
sizes of the macro expansions from nested macro calls are
correspondingly reduced (remembering that each tgmath.h macro expands
__tgmath_real_type, or sometimes now __tgmath_complex_type, several
times).
Sometimes the real return type resulted from calling a complex
function and converting the result to a real type; sometimes it
resulted from calling a real function, because the logic for
determining whether arguments were real or complex, based on sizeof,
was confused by integer promotions applying to e.g. short int but not
_Complex short int. The relevant tests are converted to use a new
macro __expr_is_real, which, by calling __builtin_classify_type rather
than comparing the results of two calls to sizeof, also reduces the
number of times macros expand their arguments.
Although there are reductions in the number of times macros expand
their arguments, I do not consider this to fix bug 21660, since a
proper fix means each macro expanding its arguments only once (via
using new compiler features designed for that purpose).
Tested for x86_64.
[BZ #21684]
* math/tgmath.h (__floating_type): Simplify definitions.
(__real_integer_type): New macro.
(__complex_integer_type): Likewise.
(__expr_is_real): Likewise.
(__tgmath_real_type_sub): Update comment to describe handling of
complex types.
(__tgmath_complex_type_sub): New macro.
(__tgmath_complex_type): Likewise.
[__HAVE_FLOAT128 && __GLIBC_USE (IEC_60559_TYPES_EXT)]
(__TGMATH_CF128): Use __expr_is_real.
(__TGMATH_UNARY_REAL_IMAG): Use __tgmath_complex_type and
__expr_is_real.
(__TGMATH_BINARY_REAL_IMAG): Likewise.
(__TGMATH_UNARY_REAL_IMAG_RET_REAL): Use __expr_is_real.
* math/gen-tgmath-tests.py (Type.create_type): Create complex
integer types.
This patch consolidates all the non cancellable nanosleep calls to use
the __nanosleep_nocancel identifier. For non cancellable targets it will
be just a macro to call the default respective symbol while on Linux
will be a internal one.
Checked on x86_64-linux-gnu, x86_64-linux-gnu-x32, and i686-linux-gnu.
* nptl/pthread_mutex_timedlock.c (__pthread_mutex_timedlock): Replace
nanosleep_not_cancel with __nanosleep_nocancel.
* sysdeps/generic/not-cancel.h (nanosleep_not_cancel): Remove macro.
(__nanosleep_nocancel): New macro.
* sysdeps/unix/sysv/linux/nanosleep.c (__nanosleep_nocancel): New
function.
* sysdeps/unix/sysv/linux/not-cancel.h (nanosleep_not_cancel): Remove
macro.
(__nanosleep_nocancel): New prototype.
