On 27/08/2025 20:41, Eduard Zingerman wrote: > On Wed, 2025-08-27 at 20:28 +0100, Alan Maguire wrote: > > [...] > >> I'm working on a small 2-patch series at the moment to improve this. The >> problem is we currently have no way to associate the DWARF with the >> relevant ELF function; DWARF representations of functions do not have >> "." suffixes either so we are just matching by name prefix when we >> collect DWARF info about a particular function. > > Oh, I see, there is no way to associate DWARF info with either > 'bpf_strnchr' or 'bpf_strnchr.constprop.0' w/o checking address. > Thank you. > >> The series I'm working on uses DWARF addresses to improve the DWARF/ELF >> association, ensuring that we don't toss functions that look >> inconsistent but just have .part or .cold suffixed components that have >> non-matching DWARF function signatures. ".constprop" isn't covered yet >> however. > > Is ".constprop" special, or just has to be allowed as one of the prefixes? > Yonghong can remind me if I've got this wrong, but .constprop is somewhat different from .part/.cold in that the latter aren't really on function boundaries. Sometimes we want to retain .constprop representations since they are function boundaries and sometimes do not mess with parameters in incompatible ways. If we can find a good heuristic for tossing them when they are not helpful as in the above case that would be great, but I'm not sure how to do that without losing BTF representations which are useful. Any suggestions on that would be really great; in the meantime I'll try and get the series dealing with .part and .cold functions out ASAP. Thanks! Alan
