Re: [RFC dwarves] btf_encoder: Remove duplicates from functions entries

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7/22/25 3:45 AM, Alan Maguire wrote:
> On 22/07/2025 00:27, Ihor Solodrai wrote:
>> On 7/21/25 7:27 AM, Jiri Olsa wrote:
>>> On Mon, Jul 21, 2025 at 12:41:00PM +0100, Alan Maguire wrote:
>>>> On 17/07/2025 16:25, Jiri Olsa wrote:
>>
>> [...]
>>
>> The current implementation is just buggy in this regard.
>>
> 
> There are a few separable issues here I think.

You're right. I think in my mind all the issues we are discussing here
boil down to a single fundamental problem: one (function) name maps to
many things. But then there are a lot of details about what those
things are, how to find them, represent them etc.

> 
> First as you say, certain suffixes should not be eligible as matches at
> all - .cold is one, and .part is another (partial inlining). As such
> they should be filtered and removed as potential matches.
> 
> Second we need to fix the function sort/search logic.

Ok, here is my stab at it. See a patch draft below.

Using ELF symbol name as the key in elf_functions table is bug-prone,
given that we lookup a name loaded from DWARF (without suffixes).

So instead of having a table of ELF sym names directly and attempting
to search there, I tried a table of unsuffixed names (assuming that
any prefix before first '.' is a proper name, which is an assumption
already present in pahole).

To not lose the information from the ELF symbols, we simply collect it
at the time that table is built, basically constructing a mapping:

    function name -> [array of elf sym info]

Then we can inspect this array when a decision about inclusion into
BTF has to made. In the patch I check for .cold and multiple
addresses.

There is little difference in resulting BTF, but the bug I reported
gets fixed with the change, as well as ambigous address problem.

Please let me know if the approach makes sense.



[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux