Re: Seen some problems with elfuitls-0.131 on x86_64

[Roland McGrath <roland at redhat dot com>]

> When we need to add a probe point to kernel, we check for  relocation
> information for it, through dwfl_module_relocations().
> For a kernel which is built without CONFIG_RELOC option,there will be 
> no relocation info. Hence I expect dwfl_module_relocations() to return 0.
> (Please correct If Iam wrong)

No, there is no feasible way to determine this from the built kernel image.
So libdwfl always assumes the kernel might be relocatable.  ELF kernels are
ET_EXEC files, but a relocatable kernel acts like ET_DYN, i.e. its whole
image is loaded at an offset from the addresses used in the ELF file
libdwfl treats kernels exactly that way, so dwfl_module_relocation_info has
one relocation, with name "", like it's described to for ET_DYN.

Previous versions of elfutils did not do this, and so relying on the
dwfl_module_relocations mechanism failed to work with running kernels that
were in fact relocated.

Systemtap ought to recognize a 1, "" dwfl_module_relocation_info as meaning
a relocatable kernel when it comes from a kernel address space Dwfl.  (Or
it can just ignore dwfl_module_relocations for the kernel module and expect
it always to require a simple runtime bias.)

When dealing with user-space objects, dwfl_module_relocations returns 0 for
ET_EXEC files, which use absolute addresses, and 1, "" for ET_DYN
(including PIE) files, which require a simple runtime bias.  


Thanks,
Roland