Need heuristics to determine when a high-confidence type should not be completely trusted #5922
Labels
Component: Core
Issue needs changes to the core
Effort: Medium
Issue should take < 1 month
Impact: Medium
Issue is impactful with a bad, or no, workaround
Type: Enhancement
Issue is a small enhancement to existing functionality
What is the feature you'd like to have?
There are a number of situations where we receive high-confidence types from places like debug info (e.g. DWARF) or the demangler and the types we receive are obviously wrong. As examples:
glibc
will not be able to "see through" GNU indirect functions and will report the wrong name, overwriting the correct name (which probably came from the demangler).QString __cdecl QString::fromUtf8(const char *str, qsizetype size)
is actually three arguments with the initial argument being a structure return type described here).In these cases, type information from a different source (or from our own analysis) might actually be more accurate than what we're being fed from external sources. It would be nice to have a "double-check" step that applies some adjustments in these situations by either combining information from multiple sources or overriding higher-confidence data.
As a first step, it might also be useful to just detect these cases and hand their resolution over to the user (e.g. by tagging them all and having some indication of what the potentially detected problem was).
Is your feature request related to a problem?
Yes, see above.
Are any alternative solutions acceptable?
Anything that arrives at the 'correct' solution in these cases should be acceptable.
Additional Information:
Binaries that exhibit both of these cases are available upon request.
The text was updated successfully, but these errors were encountered: