This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: dwfl_module_relocate_address() versus base address


> What dwfl_module_relocate_address gives me is the address compensated
> for the main elf file bias. That is the difference between the v_addr
> and p_addr of the segment. That seems fine, if the v_addr is zero.

p_paddr is wholly irrelevant to anything you'll ever do.  Ignore it.  
(Its only use is in loading the kernel before MMU hardware is enabled.)

The main ELF file's bias is the difference between what the file's headers
like p_vaddr and sh_addr say and what the actual address is in the address
space described by your Dwfl object.

> However for my libc, the bias is zero (v_addr and p_addr are equal), but
> they are non-zero (they are both 0x0000003688a00040 in my copy). 

That is normal for a prelinked DSO.  The true bias is the difference
between 0x0000003688a00040 and where that PT_LOAD actually sits in the
runtime view of your Dwfl object.  (For offline processing, that's an
arbitrary address for the arbitrary layout chosen by libdwfl.  In live
processing, it would be the actual address where the DSO got mapped.)

> So then I need to hand adjust for the v_addr afterwards to get the
> (relative) address I want. (This is the dwfl_module_info start address
> [so without bias], which I subtract after the
> dwfl_module_relocate_address call/workaround - actually I just subtract
> the start address and call it a day since we don't care about the bias in
> this case.)

The module start address is not useful here.  If the DSO's lowest p_vaddr
is 0 (i.e., it's not prelinked), then the module start address will be the
same as the main file bias.  But that does not apply to your case, which
illustrates why it is never the right term to use in a bias calculation.

The dwarf_module_getelf call gives you the main file's bias.  This is what
you need to adjust a p_vaddr/sh_addr address by to make it an absolute
address in your Dwfl's space (or vice versa, in your use here).

> What dwfl_module_relocate_address gives me is the address relative to
> the start of the elf section that the symbol lives in. 

No, it's not.  It gives you the "relocation base index", and the address
relative to that base.  In an ET_REL file, the relocation bases are ELF
sections, so there are often > 1 of them.  In an ET_DYN(-like) file, there
is only one relocation base and it's the main file's bias.

Note that the relocation base indices are tightly-packed (so you can use an
array of the size returned by dwfl_module_relocations with no waste).  A
relocation base index is purely a small number to pass to
dwfl_module_relocation_info, and is not the same as an ELF section index.

dwfl_module_relocation_info tells you the ELF section index and name for a
relocation base index.  For ET_REL this is a proper index and that
section's name.  For ET_DYN(-like) there is only one valid relocation base
index (0), for which dwfl_module_relocation_info yields SHN_ABS and "".

> That would be fine if that section starts at the beginning of the segment
> to be mapped in. Otherwise I need to adjust for the section offset (which
> is why I got the shdr from the section returned by
> dwfl_module_relocate_address in my original patch to add sh_off).

You never need this.  (sh_offset is the sections's file position, and is
never relevant to any of this.)  dwfl_module_address_section yields the
bias to apply to the sh_addr in the returned section's shdr.  Hence
gelf_getshdr(scn)->sh_addr + bias yields the absolute address of the start
of that section's contents in the Dwfl address space.

Is that all clear?


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]