readelf: Print DW_FORM_sdata values as signed numbers.

Printing DW_FORM_sdata numbers as unsigned values is misleading.

Signed-off-by: Mark Wielaard <mjw@redhat.com>
libdwfl: elf_from_remote_memory should use pagesize, not p_align.

elf_from_remote_memory would use the actual p_align of the PT_LOAD segments
to calculate the loadbase, end and start of a segment. But the dynamic
loader aligns the segments using the pagesize and only sanity checks the
p_align values. So we should do the same to get accurate segment addresses.
Also fixes a small memory leak in case the ELF image appears to be bad.

Signed-off-by: Mark Wielaard <mjw@redhat.com>
libdwfl: dwfl_linux_proc_find_elf use elf_from_remote_memory for (deleted).

If a module has a "(deleted)" main ELF file, then try to read it from
remote memory if the Dwfl has process state attached by reusing the ptrace
mechanism from linux-pid-attach.

Signed-off-by: Mark Wielaard <mjw@redhat.com>
libdwfl: dwfl_module_getdwarf.c (open_elf) only (re)set mod->e_type once.

As noted in https://sourceware.org/bugzilla/show_bug.cgi?id=16676#c2 for
systemtap, the heuristic used by open_elf to set the kernel Dwfl_Module
type to ET_DYN, even if the underlying ELF file e_type was set to
ET_EXEC, could trigger erroneously for non-kernel/non-main (debug or
aux) files.  Make sure we only set the e_type of the module once when
processing the main file (when the phdrs can be trusted).
libdwfl: test dwflsyms on ET_EXEC with minisymtab

This adds testfilebaxmin, an ET_EXEC binary with .gnu_debugdata that
doesn't match the load address of the main file.  A previous bug made
this trigger a kernel heuristic that forces the module to act like
ET_DYN, which makes things like dwfl_module_relocate_address report
relative addresses rather than proper absolute addresses.

For example, before the fix dwflsyms would print:

    deregister_tm_clones (0) 0x400430, rel: 0x430 (.text)

Now it properly prints:

    deregister_tm_clones (0) 0x400430, rel: 0x400430 (.text)

These new test additions confirm that it's fixed.

Signed-off-by: Josh Stone <jistone@redhat.com>
libdwfl: elf_from_remote_memory only trust shdrs of last file-only segment.

If the last PT_LOAD segment that contains the whole shdrs also extends
the segment in memory beyond the end of file the program might be reusing
the memory space that we expect the shdrs to be in. Don't trust the shdrs
are valid in that case.

Signed-off-by: Mark Wielaard <mjw@redhat.com>
backends: AARCH64_ABS32 and AARCH64_ABS64 are also valid in ET_REL.

This is tested now in a native aarch64 build by tests/run-elflint-self.sh
since we added some .o files to the self tests.

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