What if there is no symbol (which presumably shows up as off != 0, using whatever symbol happens to be before it)? Or it's in another file? Those are legitimate cases (the former in particular, that's for when the implementation is static, and the latter is weird but there's no reason you can't do it).

In D50683#1157061, @jrtc27 wrote:

What if there is no symbol (which presumably shows up as off != 0, using whatever symbol happens to be before it)? Or it's in another file? Those are legitimate cases (the former in particular, that's for when the implementation is static, and the latter is weird but there's no reason you can't do it).

If there's no symbol, what should we do? I don't think it's really correct to keep passing the resolver symbol's size, so should we just set it to 0 instead? In practice this case currently doesn't arise AFAICT, and so I'm rather inclined to signal the failure to the consumer.

For symbols in different linker files, we can fall back to a global search if a lookup in the current linker file fails.

In D50683#1157180, @markj wrote:

In D50683#1157061, @jrtc27 wrote:

What if there is no symbol (which presumably shows up as off != 0, using whatever symbol happens to be before it)? Or it's in another file? Those are legitimate cases (the former in particular, that's for when the implementation is static, and the latter is weird but there's no reason you can't do it).

If there's no symbol, what should we do? I don't think it's really correct to keep passing the resolver symbol's size, so should we just set it to 0 instead? In practice this case currently doesn't arise AFAICT, and so I'm rather inclined to signal the failure to the consumer.

I don't know, but I'm surprised it's not a common case already. On amd64 sure I guess you don't expect to see it, because the ET_REL .ko file probably has all the symbols for all the static functions still. Looking on arm64 it seems we still have .symtab, not just .dynsym, so the former has names still for all the static functions, and we're using ddbsymtab here which is in fact .symtab, even for link_elf. That's what the if (ef->symtab == ef->ddbsymtab) is for (confusingly named, but ef->symtab is DT_SYMTAB i.e. .dynsym); if equal, it couldn't find .symtab, so fell back on .dynsym for DDB use, but if different, it has full symbol information from .symtab. So I guess this should in fact be fine thanks to the oddities of the kernel linker.

For symbols in different linker files, we can fall back to a global search if a lookup in the current linker file fails.

Yeah, though that sounds like it could confuse FBT to get a value pointing to a different linker file's memory.

In D50683#1157196, @jrtc27 wrote:

In D50683#1157180, @markj wrote:

In D50683#1157061, @jrtc27 wrote:

What if there is no symbol (which presumably shows up as off != 0, using whatever symbol happens to be before it)? Or it's in another file? Those are legitimate cases (the former in particular, that's for when the implementation is static, and the latter is weird but there's no reason you can't do it).

If there's no symbol, what should we do? I don't think it's really correct to keep passing the resolver symbol's size, so should we just set it to 0 instead? In practice this case currently doesn't arise AFAICT, and so I'm rather inclined to signal the failure to the consumer.

I don't know, but I'm surprised it's not a common case already. On amd64 sure I guess you don't expect to see it, because the ET_REL .ko file probably has all the symbols for all the static functions still. Looking on arm64 it seems we still have .symtab, not just .dynsym, so the former has names still for all the static functions, and we're using ddbsymtab here which is in fact .symtab, even for link_elf. That's what the if (ef->symtab == ef->ddbsymtab) is for (confusingly named, but ef->symtab is DT_SYMTAB i.e. .dynsym); if equal, it couldn't find .symtab, so fell back on .dynsym for DDB use, but if different, it has full symbol information from .symtab. So I guess this should in fact be fine thanks to the oddities of the kernel linker.

For symbols in different linker files, we can fall back to a global search if a lookup in the current linker file fails.

Yeah, though that sounds like it could confuse FBT to get a value pointing to a different linker file's memory.

I don't think FBT would care. The only requirement I think of is that the kernel module which implements the ifunc is a dependency of the kernel module which returns it from a resolver. That is, if kernel module A contains an ifunc whose resolver returns a symbol from kernel module B, then kernel module B must not be unloaded. But this requirement is not specific to dtrace.