On Thu, Mar 16, 2023 at 02:51:52PM -0700, Andrii Nakryiko wrote: > Yep, Meta is also capturing stack traces with build ID as well, if > possible. Build IDs help with profiling short-lived processes which > exit before the profiling session is done and user-space tooling is > able to collect /proc/<pid>/maps contents (which is what Ian is > referring to here). But also build ID allows to offload more of the > expensive stack symbolization process (converting raw memory addresses > into human readable function+offset+file path+line numbers > information) to dedicated remote servers, by allowing to cache and > reuse preprocessed DWARF/ELF information based on build ID. > > I believe perf tool is also using build ID, so any tool relying on > perf capturing full and complete profiling data for system-wide > performance analysis would benefit as well. > > Generally speaking, there is a whole ecosystem built on top of > assumption that binaries have build ID and profiling tooling is able > to provide more value if those build IDs are more reliably collected. > Which ultimately benefits the entire open-source ecosystem by allowing > people to spot issues (not necessarily just performance, it could be > correctness issues as well) more reliably, fix them, and benefit every > user. But build IDs are _generally_ available. The only problem (AIUI) is when you're trying to examine the contents of one container from another container. And to solve that problem, you're imposing a cost on everybody else with (so far) pretty vague justifications. I really don't like to see you growing struct file for this (nor struct inode, nor struct vm_area_struct). It's all quite unsatisfactory and I don't have a good suggestion.
