On 8/27/25 12:52 PM, Alan Maguire wrote:
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
For symbol with .cold, it is not a function. It is just a jump target
from another function.
For symbol with .part, it is a actual function, but mostly like its
function signature has changed as it is part of the original
function.
For symbol with .constprop, is a clone of another function but
with less parameters, i.e., some parameters become a constant
inside the .constprop.<n> function.
With gcc build, you can see even more complicated suffixes:
ffffffff81825bf0 t __remove_instance.part.0.constprop.0
ffffffff81ed07c0 t eventfd_ctx_fileget.part.0.isra.0
...
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
It is indeed very hard to have a good heuristic for those function
with suffixes. '<func>.constprop.<n>' might be easier as you can
check location in the subprogrm, if there is no location, most
likely that parameter has become a constant inside the function.
Currently I am working on llvm to add
- function with suffixes
- function with changed signature and without suffixes.
Such infomation should have better mapping from func to
its type.
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
