Disassembler inlining

[lievenhey]

trafficstars

this adds a simple detection for inlined code to elide it from the assembly view.

I am not sure if this works correctly so it would be nice if someone has a minimal example to test this. This currently brakes syntax highlighting and code navigation

[lievenhey]

~~TODO: detect inline same file~~

[lievenhey]

The inline detection is now working.

Output:

example.c:

#include <stdio.h>

inline int square(int i) {
        return i * i;
}

int main() {
        for (int i = 0; i < 10000; i++) {
                int sum = 0;
                for (int j = 0; j < i; j++) {
                        sum += square(j);
                }
                printf("Sum: %d\n", sum);
        }
}

[GitMensch]

If it does what I think it does then: yay. Can you please share what the previous build outputs to be able to compare the results?

[lievenhey]

before: after: (click to expand an entry)

[GitMensch]

Any idea why this fails on ArchLinux with clang?

[lievenhey]

no, seems to only happen on the ci even if I ran the ci container locally, it fails to reproduce the issue

[lievenhey]

found it objdump ... on non clazy target:

00000000000012a0 <main>:
main():
/home/lieven/KDAB/hotspot/tests/test-clients/cpp-recursion/main.cpp:19

objdump ... on clazy target:

00000000000012f0 <main>:
std::basic_ios<char, std::char_traits<char> >::widen(char) const:
/opt/hotspot/tests/test-clients/cpp-recursion/main.cpp:19

I used the the first instance of something(): as function name. Since on clazy it is std::basic_ios<char, std::char_traits<char> >::widen(char) const it thinks main is an inlined function

time to rewrite it using libdwarf

[GitMensch]

related to #495

[GitMensch]

Would that need a doc update (screenshots, maybe)? Is libdwarf a new dependency to be added?

[GitMensch]

I'd like to give this a test - can you rebase that, please?

Apart from the actual inline view it will be interesting to see how the parsing with libdwarf effects the necessary time to open the disassembly view (while the time currently needed seems to be related to (the use of) Qt #505)

[GitMensch]

This will still take some time. We want to move the logic to the perfparser since it has all the logic for finding binaries etc.

Originally posted by @lievenhey in https://github.com/KDAB/hotspot/issues/518#issuecomment-1759596746

That sounds very reasonable. If I understand that correctly, this means that perfparser may use libdwarf to do this and more, and then perfparser will be used both for handling the actual "perf.data" (as now) and additionally do "something special" for the disassembly, but not replacing objdump, right?

[lievenhey]

Disassembling will still be handled by objdump. We just use libdwarf for additional information.