On Fri, Jul 21, 2023 at 10:09:31AM +0900, Masami Hiramatsu wrote: > On Thu, 20 Jul 2023 14:00:46 +0100 > Nick Alcock <nick.alcock@xxxxxxxxxx> wrote: > > > On 19 Jul 2023, Alexander Lobakin verbalised: > > > > > From: Nick Alcock <nick.alcock@xxxxxxxxxx> > > > Date: Wed, 19 Jul 2023 12:12:06 +0100 > > >>> Yes, please coordinate with Nick and review each other's work, now we > > >>> have two separate efforts with different reasons but hopefully we'll > > > > > > Three efforts[0] :D Mine went unnoticed unfortunately, so I switched to > > > other projects then. > > > > It's odd, nobody seems to have noticed these until recently and now > > suddenly people are crawling out of the woodwork wanting unique > > addresses :) maybe the ambiguous ones are just getting commonplace > > enough that they're biting people more often? > > Usually, the ambiguous symbols are used as internal functions and > are easily changed by kernel update. Thus it is only used for debugging. > On the other hand, exposed symbols are considered as more stable (It's > not really that stable.) so users tend to use that. In the use case of DTrace, tracing internal functions is certainly something that is used, be it for debugging/performance analysis, for gaining better understanding what internal operations are triggerd by userspace actions, etc. > BTW, note that `perf probe` and kprobe-events already supported that by > '_text+OFFSET' style to point those functions (`perf probe` convert the > given 'function@file-path' place to '_text+OFFSET' using DWARF and ELF). > BPF doesn't because it only supports "function name". (I'm not sure how > Dtrace support it) DTrace supports arbitrary address probing based on an offset from a symbol. > If we really consider to improve BPF trace to trace such internal functions, > I think you should consider to reuse perf-probe's code to find actual > address and convert it to '_text+OFFSET' style to specify the probe point. > > I think this still useful if user can identify the traced symbol from the > source code line, easily without DWARF analysis. And BPF also need to > support "SYMBOL+OFFSET" style probe points. While identifying a traced symbol is important, the use cases I am seeing are the other way around... being able to specify a symbol name (with whatever additional elements needed to make it unique) as target for placing a probe. And doing so without needing to depend on DWARF data or other rather large collection of debug data. Especially on production systems, requiring the typically very large debuginfo style data to be installed is not acceptable for the use cases I encounter. > > > My idea was to give relative path from the kernel root to the objfile, > > > as we have a good bunch of non-unique "filename + symbol name" pairs. > > > > I considered that, but unfortunately that has two problems to a raging > > perfectionist like me: > > > > - the objfile probably won't exist except if you're actually doing > > kernel development, since kernel build trees are big enough that a > > lot of people delete them after building or ship kernels to other > > machines: if someone else built your kernel (overwhelmingly common > > among non-kernel-devs) the objfiles are sure to be absent. (But an > > option to not truncate the names when you know they won't be absent > > might be a good idea, though this pushes space requirements up by > > hundreds of kilobytes so it should probably be off by default.) > > As I said, these internal symbol tracing is usually only for debugging > the kernel. So I think this is not so problematic. > > Thank you, > > > > > - even giving a path to the kernel module on disk (much lower > > resolution and vulnerable to ambiguity again) is unreliable because > > there's absolutely no guarantee that any given process can see any of > > them: they might be in a different fs namespace or the modules might > > only be present in an initramfs (hell, I even know setups which > > *compile* the modules needed for rootfs mounting in the initramfs! > > Yes this is borderline insane, yes it happens). More commonly, they > > might be compressed using any of a number of compressors, changing > > the name, and the kernel has no idea which compressor might have been > > used (not unless you want it to go and look, and, well, wandering > > around over the fs hunting down .ko.* files from kernelspace to get > > their names right is *not* my idea of a good time! It's hard enough > > to get that right from userspace, honestly, even with kmod helping.) > > > > The most you could do would be to provide a key you could use with > > kmod to dig the real modules out from userspace. Partial names are as > > good as anything for that :) > > > > So all the objfile names are, when it comes down to it, is names with no > > intrinsic meaning: even if they're filenames of some kind, tools can't > > rely on being able to access those files. (For my most common use case, > > using a tracer on an enterprise-built production kernel, they'd almost > > never be able to.) > > > > So you might as well treat the objfile names as arbitrary string keys > > that might be a memory-jogger for humans, which means you can chop > > boring bits off them to save space :) > > > -- > Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>
