__elf_xfctstof is only used in case the memory size and file size of ELF
data structures are different. This is never the case.

Signed-off-by: Mark Wielaard <mark@klomp.org>

Those functions were intended for ELF versions where the memory and
file sizes of data structures are different. They were never used
because libelf depends on the file and memory sizes being equal
(otherwise using mmap wouldn't work).

Signed-off-by: Mark Wielaard <mark@klomp.org>

Remove (partially defined out) code and data structures dealing with
multiple ELF versions. There hasn't been a new ELF version in the
last 20 years. Simplify the code a bit by just assuming there will
only be one version (EV_CURRENT == 1).

Simplifies elf_version, gets rid of __libelf_version_initialized.
Removes one (or more) array (version) dimension from various tables
and accessor functions (__elf_xfctstom, shtype_map, __libelf_data_type,
__libelf_type_aligns and __libelf_type_sizes).

Signed-off-by: Mark Wielaard <mark@klomp.org>`

GCC9 -Wmissing-attributes pointed out that although we alias the fsize
and msize functions only fsize was marked as const. Fix by also marking
the msize definition as const.

https://sourceware.org/bugzilla/show_bug.cgi?id=23884

Signed-off-by: Mark Wielaard <mark@klomp.org>

GNU Property notes are different from normal notes because they use
variable alignment/padding of their fields. They are 8 byte aligned,
but use 4 byte fields. The name is aligned at 4 bytes and padded so
that, the desc is aligned at 8 bytes. The whole note is padded to
8 bytes again. For normal notes all fields are both 4 bytes wide and
4 bytes aligned.

To recognize these new kind of ELF Notes a new Elf_Type is introduced,
ELF_T_NHDR8. This type is used in the xlate functions to determine
how to align and pad the various fields. Since the fields themselves
can now have different alignments we will have to keep track of the
current alignement and use either NOTE_ALIGN4 or NOTE_ALIGN8 to
determine the padding.

To set the correct Elf_Type on the Elf_Data we use either the section
sh_addralign or the segment p_align values. Assuming 8 means the
section or segment contains the new style notes, otherwise normal
notes.

When we cannot determine the "alignment" directly, like when parsing
special kernel sys files, we check the name "GNU" and type
"GNU_PROPERTY_TYPE_0" fields.

ebl_object_note now parses the new NT_GNU_PROPERTY_TYPE_0 and can
extract the GNU_PROPERTY_STACK_SIZE, GNU_PROPERTY_NO_COPY_ON_PROTECTED
and GNU_PROPERTY_X86_FEATURE_1_AND types GNU_PROPERTY_X86_FEATURE_1_IBT
and GNU_PROPERTY_X86_FEATURE_1_SHSTK.

Tests are added for extracting the note from sections or segments
as set by gcc -fcf-protection.

Signed-off-by: Mark Wielaard <mark@klomp.org>

For i386 and x86_64 we allow some unaligned data accesses.
We also return unaligned data from elf_getdata[_rawchunk].
But that might go wrong if we then access the ELF types inside.
When build with gcc -O3 for example the compiler might vectorize
loops accessing ELF words or types. The instructions used do require
the data is naturally aligned. If the function returnes unaligned
data the program will segfault and crash. This happens for example
with the code in dwfl_module_getdwarf.c that tries to iterate over
the hash buckets gotten through elf_getdata_rawchunk based on the
DT_[GNU]_HASH value.

This only happens when the underlying ELF file is mmapped, and it
is meant as optimization so that we don't have to copy data first
so that it is correctly aligned. In most cases the data is already
naturally aligned though. But it might not be for non-native ELF
files.

Given that it might even happen in our own code base and these
are public functions that can be used by code that might rely on
the data returned being correctly aligned for the ELF data type
requested just always return correctly aligned data.

Signed-off-by: Mark Wielaard <mark@klomp.org>

Add ELF_E_INVALID_ELF which is set when the ELF file data is bad.
This is different from ELF_E_INVALID_FILE which is set when the file
could not be read.

Signed-off-by: Mark Wielaard <mark@klomp.org>

If so, define attribute_hidden to be empty. Also, use attribute_hidden
in all places where we hide symbols. If this attribute is missing, it
simply means that we cannot hide private symbols in the binary using
attributes. This disables some optimizations and may increase the risk
of symbol name clashes with other libraries, but is not fatal.

However, we still employ linker version scripts to explicitly define
the exported symbols. This serves much of the same purpose. Also, as
all our symbols are prefixed with the library name, and "__" for
private ones, the chance of clashes is low anyway.

Signed-off-by: Ulf Hermann <ulf.hermann@qt.io>

config.h doesn't have include guards, so including it twice is bad. We
deal with this by checking for PACKAGE_NAME, but only in some places.
Once we start using gnulib, we will need to include config.h before any
gnulib-generated headers. This is problematic if we include it
transitively through our own private headers.

In order to set a clear rule about inclusion of config.h, it is now
included in every .c file as first header, but not in any header. This
will definitely avoid double-inclusion and satisfy the condition that it
has to be included before gnulib headers. It comes at the price of
adding some redundancy, but there is no clean way to avoid this.

Signed-off-by: Ulf Hermann <ulf.hermann@qt.io>

The testcase added to run-strip-reloc.sh for strip-compressed.o showed
a memory leak when ran under valgrind (configure --enable-valgrind).

For a mmapped ELF file when existing section data was compressed
elf_end would fail to release the new compressed data buffer assigned
to rawdata_base. For non-mapped files rawdata_base is always freed.
For decompressed data rawdata_base is released together with zdata_base.

Use the Elf_Scn flag ELF_T_MALLOCED to track whether rawdata_base
points to malloced memory and free it in elf_end even for mmapped
ELF files.

Signed-off-by: Mark Wielaard <mjw@redhat.com>