Includes changes to handle the Linux syscall blocking when there is not
enough entropy during boot, by switching it to non-blocking mode and
falling back to the alternative implementations. Man page URL reference
fixes. Build fixes for Mac OS X.
Fixes: https://bugs.debian.org/898088
uClibc defines EM_OR1K instead of EM_OPENRISC for the OpenRISC ELF
e_machine ID. Use EM_OR1K when EM_OPENRISC is not defined.
This fixes the following build failure:
In file included from nlist.c:44:0:
nlist.c: In function ‘__elf_is_okay__’:
local-elf.h:224:23: error: ‘EM_OPENRISC’ undeclared (first use in this function)
#define ELF_TARG_MACH EM_OPENRISC
^
nlist.c:77:26: note: in expansion of macro ‘ELF_TARG_MACH’
if (ehdr->e_machine == ELF_TARG_MACH &&
^
Signed-off-by: Guillem Jover <guillem@hadrons.org>
On non-glibc based systems we cannot unconditionally use the
__GLIBC_PREREQ macro as it gets expanded before evaluation. Instead,
if it is undefined, define it to 0.
We should also always declare these functions on non-glibc based
systems. And on systems with a new enough glibc, which provides these
functions, we should still provide the declarations if _GNU_SOURCE
is *not* defined.
Reported-by: Jörg Krause <joerg.krause@embedded.rocks>
This is a non-portable header, and we cannot expect it to be provided by
the system libc (e.g. musl). We just need and rely on declaration that
we have defined ourselves in our own <bsd/sys/cdefs.h>. So we switch to
only ever assume that.
Fixes: https://bugs.freedesktop.org/105281
On IA64 this is only the case in the ELF binary, but it gets normalized
when loaded at run-time.
Fixes: https://bugs.debian.org/881611
Signed-off-by: Guillem Jover <guillem@hadrons.org>
We mention that these are now superseded by the glibc implementations,
make the headers cope with already declared functions on glibc-based
systems, and document this in the man pages.
The two arrays might not reference contiguous memory, and assuming they
are does break at least now on GNU/Hurd, which contains an unmapped
memory block between the memory used by the two arrays.
Just check that each element is strictly after the previous one, so that
we know there are no unmapped memory blocks inbetween.
At least on IA64 and PowerPC 64-bit ELFv1, the functions are stored in
the .text sections but they are accessed through a function descriptor
stored in a data section, for example for PowerPC 64-bit ELFv1 that
section is called .opd.
We should take this into account when checking the n_type for the
functions we have requested information from nlist().
Rationale-by: James Clarke <jrtc27@jrtc27.com>
We have moved all man pages to section 3bsd, let's do the same for the
page title, and in all the references for uniformity and to avoid
confusions.
Fixes: https://bugs.freedesktop.org/101545
Add a check for _MIPS_SIM inside the __mips__ #elif to detect mips64el
and use ELFCLASS64 in that case. Note that we can't use defined(__mips64)
here because that is also defined when the n32 ABI is in use, which uses
ELFCLASS32.
Fixes: https://bugs.debian.org/865091
Signed-off-by: Guillem Jover <guillem@hadrons.org>
* ppc64el defines both __powerpc__ and __powerpc64__ but since the
__powerpc64__ #elif is below the __powerpc__ one, it will never be hit.
* Both assumed that powerpc* was big-endian.
Fixes: https://bugs.debian.org/865091
Signed-off-by: Guillem Jover <guillem@hadrons.org>
The offset is not page aligned, which makes mmap() return EINVAL on
Linux. Switch to use pread() which handles unaligned offset and non-page
sized reads, and because we are already loading parts of the executable
by read() calls, so there's not much point in using mmap() anyway.
Some libc libraries do not have an <a.out.h> header. And a.out as an
executable format is very much obsolete on pretty much all currently
supported systems, even if they might still support loading such
objects.
Remove the a.out support to increase portability.
Backport new changes from OpenBSD.
[guillem@hadrons.org:
- Update copyright years in COPYING. ]
References: https://svnweb.freebsd.org/base?view=revision&revision=281135
Signed-off-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
Signed-off-by: Guillem Jover <guillem@hadrons.org>
