Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3 |
|
#
c1d55d26 |
| 21-Apr-2023 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Let Mangled decide whether a name is mangled or not
We have a handful of places in LLDB where we try to outsmart the logic in Mangled to determine whether a string is mangled or not. There's
[lldb] Let Mangled decide whether a name is mangled or not
We have a handful of places in LLDB where we try to outsmart the logic in Mangled to determine whether a string is mangled or not. There's at least one place (*) where we are getting this wrong and causes a subtle bug. The `cstring_is_mangled` is cheap enough that we should always rely on it to determine whether a string is mangled or not.
(*) `ObjectFileMachO` assumes that a symbol that starts with a double underscore (such as `__pthread_kill`) is mangled. That's mostly harmless, until you use `function.name-without-args` in the frame format. The formatter calls `Symbol::GetNameNoArguments()` which is a wrapper around `Mangled::GetName(ePreferDemangledWithoutArguments)`. The latter will first try using the appropriate language plugin to get the demangled name without arguments, and if that fails, falls back to returning the demangled name. Because we forced Mangled to treat the symbol as a mangled name (even though it's not) there's no demangled name. The result is that frames don't show any symbol at all.
Differential revision: https://reviews.llvm.org/D148846
show more ...
|