mib marked 6 inline comments as done. mib added a comment. I'll investigate matching the symbol by address instead of name, but I still think having the ability to register a recognizer with multiple symbols can be useful.
In D76188#1924083 <https://reviews.llvm.org/D76188#1924083>, @labath wrote: > Being able to match multiple symbols sounds useful in its own right, but the > motivating case is a bit shady. `raise`, `__GI_raise` and `gsignal` are all > aliases to one another (they have the same address). The reason you're > sometimes getting `gsignal` here is not because some glibcs really call this > function from their assert macro. It's because we happen to pick that symbol > (maybe because it comes first in the symtab, depending on how the library was > linked) when doing address resolution. > > I'm wondering if that doesn't signal a flaw in the recognizer infrastructure. > If we changed the matching logic so that it resolves the name it is supposed > to search for, and then does a match by address, then only one name would be > sufficient here. ================ Comment at: lldb/source/Commands/CommandObjectFrame.cpp:880 auto func = - RegularExpressionSP(new RegularExpression(m_options.m_function)); + RegularExpressionSP(new RegularExpression(m_options.m_symbols.front())); StackFrameRecognizerManager::AddRecognizer(recognizer_sp, module, func); ---------------- labath wrote: > Is there something which ensure that m_symbols contains at least one element > here? (i.e., that we do not silently drop the extra symbols arguments) Few lines above, we make sure the symbols list is not empty. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D76188/new/ https://reviews.llvm.org/D76188 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
