Re: PR10000: emit _stp_relocate* calculations correctly for kernel/module global $data (Was: [SCM] systemtap: system-wide probe/trace tool branch, master, updated. release-0.9-238-g432f054)

[Roland McGrath <roland@redhat.com>]

> So what we could do at this time is make sure sym.value is between the
> reported base of the module and the end of the module as returned by
> dwfl_module_info() Then at least we only process "sane values" (even
> though they might not be real function or data symbols).

That seems like a reasonable heuristic.

> We exclude those since in some kernels on some architectures have vDSO
> names marked as SHN_ABS && STT_FUNC (instead of STT_NOTYPE). Maybe we
> should move the SHN_ABS check to only the kernel module.

Ah, right.  Or perhaps just use the heuristic above to cover that case.

> > For anal reasons, the &shndx filled by dwfl_module_getsym is what you use
> > for the actual symbol, not st_shndx--but st_shndx is what you test for the
> > SHN_* constants.
> 
> ehm, ok, odd.

SHN_LORESERVE is 0xff00, so to have more than 65279 sections, the indices
have to be treated disjointly from the st_shndx values that might be those.

> Nice, that is the interface I want!

Ok, I'll merge it for 0.141.

> Unfortunately we also have to work with older versions.
> But I guess I can already add the check for shndxp != -1 and it will
> start working properly with newer versions.

Yes.  And you might use an _ELFUTILS_PREREQ check around the heuristic you
apply to filter out the uninteresting symbols.  Or, you could use getelf
and getscn and check for SHF_ALLOC--a real, proper check, not a heuristic
guess.  You'd definitely want that code only under _ELFUTILS_PREREQ, since
it introduces undesireable performance effects.


Thanks,
Roland