Disassembler inlining

[lievenhey]

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 #518 (comment)

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.

[GitMensch]

@lievenhey Is there a specific reason to keep this as a draft? If not, it would be nice to rebase and mark as "ready to merge" (actually a rebase would be nice in any case).

[lievenhey]

Well for one it doesn't work that good and I hadn't much time to work on this.
We recently discussed using a real disassembly library so this will soon be out of date.
The reason is, that we are currently try to parse the human readable output of objdump, but that doesn't work so well with more complex information.