On Thu, 28 Aug 2025 18:00:22 -0300
Arnaldo Carvalho de Melo [off-list ref] wrote:

quoted

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?"

The "if one exists" comment is that it's not a requirement. If none
exists, it would just add a zero.

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.

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.

Would perf be interested in this hash file lookup?

I know perf is reliant on user space more than ftrace is, and has a lot
of work happening in user space while getting stack traces. With
ftrace, there's on real user space requirement, thus a lot of the work
needs to be done in the kernel.

If we go with a hash to file, it's somewhat useless by itself without a
way to map the hash to file/buildid.

I originally started making this hash->file a file in tracefs. But then
I needed to figure out how to manage the allocations. Do I add a "size"
for that file and start dropping mappings when it reaches that limit.
Then I may need to add a LRU algorithm to do so. I found simply having
an event that wrote out the mappings was so much easier to implement.

But the file_cache code could be used by perf, where perf does the same
and just monitors the file_cache event. I could make the API more
global than just the kernel/trace directory.

-- Steve