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


Hi Roland,

On Tue, 2008-12-16 at 01:11 -0800, Roland McGrath wrote:
> Since this code does getelf anyway (which, incidentally, imposes all the
> costs of dwfl_module_address_section on every section), you can just do a
> different workaround.  You can even skip the bad overhead, because you
> don't need to do any workaround for ET_REL files anyway:
> 
> 	if (ki == 0 && secname != NULL && secname[0] == '\0')
> 	  {
> 	    check for bug
> 	  }
> 
> So, you can do getelf + getdwarf, to get mainbias and dwbias, respectively.
> If mainbias == dwbias, you are already correct.  To check for the bug,
> you'd see if the original sym_addr and the sym_addr adjusted by
> dwfl_module_relocate_address mainbias or by dwbias.  But, if you just want
> to work right rather than test for the bug, you can just do:
> 
> 	Dwarf_Addr save_addr = sym_addr;
> 	int ki = dwfl_module_relocate_address (m, &sym_addr);
> 	dwfl_assert ("dwfl_module_relocate_address", ki >= 0);
> 	secname = dwfl_module_relocation_info (m, ki, NULL);
> 	if (ki == 0 && secname != NULL && secname[0] == '\0')
> 	  {
> 	    Dwarf_Addr bias;
> 	    dwfl_assert ("dwfl_getelf", dwfl_module_getelf (m, &bias) != NULL);
> 	    sym_addr = save_addr - bias;
> 	  }

Thanks again. Slowly I will actually understand what libdwfl does :)

But this is not fully working for me against my libc. Lets trace what I
do and what this workaround does (aka what dwfl_module_relocate_address
is supposed to do). I might just not fully comprehend the address
adjustments that both these functions are doing.

What I want is the address of a symbol relative to the start of where
the elf segment is (will be) loaded in memory.

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.
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). 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.)

What dwfl_module_relocate_address gives me is the address relative to
the start of the elf section that the symbol lives in. 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).

Does the above make sense? Does the above description explain what these
functions are supposed to do to the given address? And are the fixups
that I need do expected for my particular use case?

Thanks,

Mark


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