We already have the value computed based on the executable. Furthermore,
debuginfo need not have valid program header table, thus the result
might be bogus.
Signed-off-by: Martin Milata <mmilata@redhat.com>
The ppc64 implementation of tdep_get_func_addr would crash when
attempting to retrieve the address of a function in a shared
library. The problem was that it needs to dereference the
function descriptor, but common code was passing the *unrelocated*
adddress of the descriptor to the tdep_get_func_addr routine.
Instead, common code would attempt to relocate the *result* of
tdep_get_func_addr, which is also wrong: the ppc64 implementation
reads the function address from the in-memory copy of the
descriptor, which is already relocation and contains the final
address.
This patch fixes the problem by relocating the descriptor address
before passing it to tdep_get_func_addr, instead of relocating
the result of tdep_get_func_addr. Since ppc64 is the only
non-trivial implementation of tdep_get_func_addr, this cannot
affect any other platform.
Signed-off-by: Ulrich Weigand <uweigand@de.ibm.com>
Make sure that we have included `config.h' before checking HAVE_LZMA.
This makes a difference at least on MIPS, where we include `elfxx.c'
directly. For other platforms this does not make much difference, as we
are already indirectly including `config.h' from other headers.
After searching the normal symbol table, look if the binary contains
.gnu_debugdata section. If it does, run LZMA decompression on it, load
the resulting ELF image into memory and call lookup_symbol() on it
again.
lookup_symbol() is modified so that it takes min_dist as a parameter and
only returns a symbol when it finds one that is closer than indicated by
the parameter.
Signed-off-by: Martin Milata <mmilata@redhat.com>
The code for symbol lookup (elfxx.c:lookup_symbol) works by iterating
over symbol tables while maintaing the symbol closest to the supplied
instruction pointer. Whenever this search encountered symbol that was
longer than result buffer, the function returned -UNW_ENOMEM even though
the final symbol wasn't too long.
Signed-off-by: Martin Milata <mmilata@redhat.com>
routine and add address-space argument. This is needed because on
PPC64, a the function-name symbol refers to a function descriptor
(unlike, for example, on ia64, where the @fptr() operator is needed to
refer to a function descriptor). Thus, in order to look up the name
of a function, we need to dereference the function descriptor. To
make matters more "interesting", the function descriptors are normally
resolved by the dynamic linker, so we can't get their values from the
ELF file. Instead, we have to read them from the running image, hence
the need for the address-space argument.
Return -UNW_ENOMEM if string buffer is too small. This makes the routine
compatible with the definition of the unw_get_proc_name(3).
(Logical change 1.63)
