In this section, we discuss the Executable Results table. Each row of this table corresponds to one executable in the database. The information in one row is an aggregation of all of the function-level matches into that row's executable. Here is an example Executable Results table from the previous query (yours may look different depending on the compiler used to create the example files):
If you select a single row in the table and right-click on it, you will see the following actions:
foo
has 2 or more matches into a given executable, it still only contributes 1 to the function count).
What position is demangler_gnu_v2_41
in your table?foo
has more than one match into a given executable, only the one with the highest (function-level) confidence contributes to the (executable-level) confidence score.
Sort the Executable results by descending confidence and observe that demangler_gnu_v2_41
is now further down the list.
demangler_gnu_v2_41
and apply the filter action.
Sort the filtered function matches by descending confidence.
Starting at the top, examine some of the matches and convince yourself that the given explanation is correct.
demangler_gnu_v2_41
and query all functions in postgres
again, this time with a Confidence bound slightly higher than this confidence value. Verify that demangler_gnu_v2_41
is not in the list of executable matches.From this exercise, we see that unrelated functions can be duplicates of each other, either because they are small or because they perform a common generic action. Keep in mind that such functions can "pollute" the results of a blanket query. In the next section, we demonstrate a technique to restrict queries to functions which are more likely to have meaningful matches.
Next Section: Overview Queries