We fake initialization of notes with an empty asm statement.  But
it is simpler and less confusing to just initialize notes just
before the fopen.

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

The inode number in /proc/pid/maps is displayed as "unsigned long"
type.

In one of our x64 system, we have inode number exceeding valid "long"
type range, which caused the following test failure:
   FAIL: dwfl-bug-fd-leak
   FAIL: run-backtrace-dwarf.sh
   FAIL: vdsosyms

The offending map entry:
  7f269246b000-7f269246c000 rw-p 0002e000 00:50 10224326387095067468 /home/...

This patch changed sscanf inode number type from PRIi64 to PRIu64
and fixed the problem.

Signed-off-by: Yonghong Song <yhs@fb.com>

When reading the dyn data from the core file check if we got everything,
or just part of the data.

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

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

Most strings in core notes are fixed size. But NT_PLATFORM contains just
a variable length string. Check that it is actually zero terminated
before passing to readelf to print.

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

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

We would not relocate when the relocation section data or the target
section date would overlap with one of the ELF headers. This is only
really necessary if the data comes directly from the mmapped file.
Otherwise there is no real overlap and the relocations can be safely
applied.

One particular thing we got wrong with the original sanity check was
when the relocation data or target data section was compressed. In
that case it could happen we overestimated the size (because the Shdr
would have been updated to show the uncompressed data size). But
uncompressed data is always malloced and so cannot overlap with the
mmapped Elf header structures.

When building with CFLAGS="-g -Og" this showed up as a failure in
run-strip-reloc.sh for strip-compressed.o. Where the .debug_loc
section decompressed would "overlap" with the shdrs at the end of
the file and so wouldn't get relocations applied.

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

This introduces a new function dwelf_elf_begin which creates a (read-only)
ELF handle from a possibly compressed file handle or a file that start
with a linux kernel header. This can be used in eu-readelf to (re)open a
(pure) ELF.

eu-readelf uses libdwfl to relocate addresses in the original file in
case it is ET_REL. But to show the "raw" data it might need to (re)open
the file. Which could fail if the file was compressed. And produced an
obscure error message: "cannot create EBL handle".

This rewrites __libdw_open_file a little so that the given file handle
will never be closed (whether on success or failure) and introduces a
new internal function __libdw_open_elf that dwelf_elf_begin wraps.

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>

There were some recent bug reports where we trusted the ELF section header
to be sane and divided the sh_size by the sh_entsize to get the number of
objects in the section. This would cause a divide by zero if the file was
corrupt and the sh_entsize was zero. Add checks for any such code.

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

There were two issues when reading note data from a core file.
We didn't check if the data we already had in a buffer was big
enough. And if we did get the data, we should check if we got
everything, or just a part of the data.

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

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

This adds support for ADD and SUB relocations as seen on RISC-V.

Signed-off-by: Andreas Schwab <schwab@suse.de>