On Thu, Dec 10, 2020 at 09:02:05AM -0800, Andrii Nakryiko wrote: SNIP > > yes, ELF symbol's value is 4, but when iterating DWARF variables > (0x10e70 + 4) is returned. It does look like a special handling of > modules. I missed that libdw does some special things for specifically > modules. Further debugging yesterday showed that 0x10e70 roughly > corresponds to the offset of .data..per_cpu if you count all the > allocatable data sections that come before it. So I think you are > right. We should probably centralize the logic of kernel module > detection so that we can handle these module vs non-module differences > properly. > > > > > not sure this is related but looks like similar issue I had to > > solve for modules functions, as described in the changelog: > > (not merged yet) > > > > btf_encoder: Detect kernel module ftrace addresses > > > > ... > > There's one tricky point with kernel modules wrt Elf object, > > which we get from dwfl_module_getelf function. This function > > performs all possible relocations, including __mcount_loc > > section. > > > > So addrs array contains relocated values, which we need take > > into account when we compare them to functions values which > > are relative to their sections. > > ... > > > > The 0x10e74 value could be relocated 4.. but it's me guessing, > > because not sure where you see that address exactly > > > It comes up in cu__encode_btf(), var->ip.addr is not 4, as we expect it to be. I'm taking section sh_addr for each function and relocate the addr value for kernel modules, check setup_functions function I don't see this being somehow centralized, looks simple enough to me for each case jirka
