Re: dwfl_module_relocate_address() versus base address

[Mark Wielaard <mjw@redhat.com>]

Hi Roland,

On Wed, 2008-12-17 at 15:08 -0800, Roland McGrath wrote:
> > The one remaining issue is finding the correct p_vaddr. I must be
> > missing the obvious. Currently I am just going through all program
> > headers to try and find the correct one (after adjusting sym_addr for
> > the elf main file bias):
> 
> Something is not all clear to at least one of us, because I have no idea
> why you think you need to do anything like this.

OK. Lets go to the start and see if from that it does or doesn't follow
that I want to adjust for the p_vaddr of the segment that the address is
in to get a relative offset.

What we do at translation time is create a table of symbol addresses
that we can look up against at run time so that when we see an address
in a segment that was mapped in we can use that lookup table for that
module and provide the corresponding symbol name. (This was my earlier
work mapping the vma table from the task finder to the corresponding
_stp_module). Since we don't know where the segment will be mapped into
the user address space beforehand we need the symbol addresses to be
relative to the start of segment that gets loaded.

So to get these relative addresses for shared libraries for each
stp_module in translate.cxx we have dump_unwindsyms() which is the
callback for dwfl_getmodules(). To build up a symbol table (as put in
stap-symbols.h) that is relative to the start of where the elf segment
is (will be) loaded in memory we do the following there:
- dwfl_module_getsymtab() to get the number of symbols in the module.
  Then for each symbol:
  - dwfl_module_getsym() to get the symbol values.
  - dwfl_module_relocate_address() to adjust the address to the base.
  - dwfl_module_relocation_info() to get the base information
    (so we know the section name, etc so we know whether it is a
     dynamic address.)
  - Get the p_vaddr of the segment that the symbol address is in
    so we can make the address relative to the segment load address.

It is the last step that seems a bit cumbersome. So if we can come up
with a way to avoid it that would be nice.

Cheers,

Mark