Arnaldo Carvalho de Melo <arnaldo.melo@xxxxxxxxx> writes: > On August 28, 2025 5:51:39 PM GMT-03:00, Steven Rostedt <rostedt@xxxxxxxxxx> wrote: >>On Thu, 28 Aug 2025 17:27:37 -0300 >>Arnaldo Carvalho de Melo <arnaldo.melo@xxxxxxxxx> wrote: >> >>> >I would love to have a hash to use. The next patch does the mapping >>> >of the inode numbers to their path name. It can >>> >>> The path name is a nice to have detail, but a content based hash is >>> what we want, no? >>> >>> Tracing/profiling has to be about contents of files later used for >>> analysis, and filenames provide no guarantee about that. >> >>I could add the build id to the inode_cache as well (which I'll rename >>to file_cache). >> >>Thus, the user stack trace will just have the offset and a hash value >>that will be match the output of the file_cache event which will have >>the path name and a build id (if one exists). >> >>Would that work? > > Probably. > > This "if it is available" question is valid, but since 2016 it's is more of a "did developers disabled it explicitly?" > > If my "googling" isn't wrong, GNU LD defaults to generating a build ID in ELF images since 2011 and clang's companion since 2016. GNU ld doesn't ever default to generating build IDs, and I don't *think* LLVM does either (either in Clang, or LLD). GCC, on the other hand, has a configure arg to control this, but it's default-off. Clang generally prefers to have defaults like this done via user/sysadmin specified configuration files rather than adding build-time configure flags. Now, is it a reasonable ask to say "we require build IDs for this feature"? Yeah, it probably is, but it's not default-on right now, and indeed we in Gentoo aren't using them yet (but I'm working on enabling them). > > So making it even more available than what the BPF guys did long ago > and perf piggybacked on at some point, by having it cached, on > request?, in some 20 bytes alignment hole in task_struct that would be > only used when profiling/tracing may be amenable. thanks, sam
