[Lldb-commits] [PATCH] D74759: Treat RangeDataVector as an augmented BST

jarin added a comment. In D74759#1880499 , @labath wrote: > I like this idea a lot, in principle. It is much simpler than a full blown > interval tree, and it should give us similar performance characteristics. > > Have you done a proper complexity

[Lldb-commits] [PATCH] D74759: Treat RangeDataVector as an augmented BST

jarin added a comment. Thanks for putting this together, some comments below. Let us see what Pavel thinks. Comment at: lldb/include/lldb/Utility/RangeMap.h:634 + // We can treat the vector as a flattened BST, augmenting it with upper bounds (max of + // range endpoints)

[Lldb-commits] [PATCH] D74217: Add target.xml support for qXfer request.

jarin added inline comments. Comment at: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp:2814 + +if (reg_info->invalidate_regs && reg_info->invalidate_regs[0]) { + response.PutCString("invalidate_regnums=\""); I know this is

[Lldb-commits] [PATCH] D74217: Add target.xml support for qXfer request.

jarin added inline comments. Comment at: lldb/packages/Python/lldbsuite/test/tools/lldb-server/registers-target-xml-reading/TestGdbRemoteTargetXmlPacket.py:69 +self.assertEqual(q_info_reg["offset"], xml_info_reg.get("offset")) +

[Lldb-commits] [PATCH] D74217: Add target.xml support for qXfer request.

jarin added inline comments. Comment at: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp:465 + response.PutChar(','); +response.Printf("%" PRIx32, *reg_num); + } I think this is not correct: target.xml expects this to be

[Lldb-commits] [PATCH] D74398: [lldb-server] jThreadsInfo returns stack memory

jarin added a comment. Thank you for the feedback! I am a bit busy with other things ATM, but I should be able to get back to this next week. I should give credit where it's due - Pavel pointed me to the debug-server code and I took the idea from there. We do not always have the frame pointer

[Lldb-commits] [PATCH] D74398: [lldb-server] jThreadsInfo returns stack memory

jarin created this revision. jarin added a reviewer: labath. jarin added a project: LLDB. Herald added a subscriber: lldb-commits. This patch adds parts of the stack that should be useful for unwinding to the jThreadsInfo reply from lldb-server. We return the top of the stack (12 words), and we

[Lldb-commits] [PATCH] D74217: Add target.xml support for qXfer request.

jarin added inline comments. Comment at: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp:2819 +response.Printf(""); +const int registersCount = 128; +for (int reg_index = 0; reg_index < registersCount; reg_index++) { As

[Lldb-commits] [PATCH] D73191: Only match mangled name in full-name function lookup (with accelerators)

jarin added a comment. In D73191#1841372 , @labath wrote: > (I mean, if there is a real benefit to having some queries return only > non-methods, then we can certainly do something like that as well, but that > should be handled differently -- either we

[Lldb-commits] [PATCH] D73191: Only match mangled name in full-name function lookup (with accelerators)

jarin added a comment. Pavel, could you take another look, please? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D73191/new/ https://reviews.llvm.org/D73191 ___ lldb-commits mailing list lldb-commits@lists.llvm.org

[Lldb-commits] [PATCH] D73191: Only match mangled name in full-name function lookup (with accelerators)

jarin updated this revision to Diff 240480. jarin retitled this revision from "Ignore methods in full-name function lookup (with accelerators)" to "Only match mangled name in full-name function lookup (with accelerators)". jarin edited the summary of this revision. jarin added a comment. Only

[Lldb-commits] [PATCH] D73191: Ignore methods in full-name function lookup (with accelerators)

jarin marked an inline comment as done. jarin added inline comments. Comment at: lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.cpp:45 if (name_type_mask & eFunctionNameTypeFull) { -dies.push_back(die); -return; +if (!die.IsMethod() || die.GetMangledName(false)

[Lldb-commits] [PATCH] D73191: Ignore methods in full-name function lookup (with accelerators)

jarin marked an inline comment as done. jarin added inline comments. Comment at: lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.cpp:45 if (name_type_mask & eFunctionNameTypeFull) { -dies.push_back(die); -return; +if (!die.IsMethod() || die.GetMangledName(false)

[Lldb-commits] [PATCH] D73191: Ignore methods in full-name function lookup (with accelerators)

jarin added a comment. Pavel, does the latest patch address (and test) what you were worried about? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D73191/new/ https://reviews.llvm.org/D73191 ___ lldb-commits mailing list

[Lldb-commits] [PATCH] D73191: Ignore methods in full-name function lookup (with accelerators)

jarin updated this revision to Diff 240144. jarin edited the summary of this revision. jarin added a comment. Updated to include all methods/non-methods with matching mangled name. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D73191/new/ https://reviews.llvm.org/D73191 Files:

[Lldb-commits] [PATCH] D69309: Support template instantiation in the expression evaluator

jarin added a comment. > FWIW, the Sony debugger throws away the `` part of the DW_AT_name and > reconstructs it from the template_parameter children. The presence of > typedefs and/or enums can make the `` text inconsistent, especially > across enums. Our debugger reconstructs the

[Lldb-commits] [PATCH] D73191: Ignore methods in full-name function lookup (with accelerators)

jarin created this revision. jarin added a reviewer: labath. jarin added a project: LLDB. Herald added subscribers: lldb-commits, arphaman, aprantl. In the spirit of https://reviews.llvm.org/D70846, we only return non-methods in Apple/DebugNamesDWARFIndex::GetFunction if eFunctionNameTypeFull is

[Lldb-commits] [PATCH] D69933: [ASTImporter] Limit imports of structs

jarin updated this revision to Diff 239235. jarin added a comment. Herald added a subscriber: lldb-commits. I changed the diff so that it does not touch Clang's AST importer, instead it patches LLDB's wrapper of the AST importer. The idea is to only import complete a record if the current

[Lldb-commits] [PATCH] D72133: Data formatters: Look through array element typedefs

jarin added a comment. Raphael, could you possibly land the patch for me? Thanks! CHANGES SINCE LAST ACTION https://reviews.llvm.org/D72133/new/ https://reviews.llvm.org/D72133 ___ lldb-commits mailing list lldb-commits@lists.llvm.org

[Lldb-commits] [PATCH] D72133: Data formatters: Look through array element typedefs

jarin added a comment. In D72133#1806822 , @clayborg wrote: > So as long as the following are true from this patch I am ok: > > - if I ask for the array element type of "str" in the test that was added, it > should return "MCHAR". We shouldn't be

[Lldb-commits] [PATCH] D72133: Data formatters: Look through array element typedefs

jarin marked 3 inline comments as done. jarin added inline comments. Comment at: lldb/source/API/SBType.cpp:215-218 + CompilerType canonical_type = + m_opaque_sp->GetCompilerType(true).GetCanonicalType(); + return LLDB_RECORD_RESULT( + SBType(TypeImplSP(new

[Lldb-commits] [PATCH] D72133: Data formatters: Look through array element typedefs

jarin added a comment. Actually, there is something unusually flaky in my current checkout, so you might be right that not canonicalizing is harmless. It still makes more sense to land that separately. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D72133/new/

[Lldb-commits] [PATCH] D72133: Data formatters: Look through array element typedefs

jarin marked an inline comment as not done. jarin added a comment. In D72133#1802727 , @teemperor wrote: > Also do you need someone to commit this for you? Yes, please (once we agree what to do with SBType.cpp). CHANGES SINCE LAST ACTION

[Lldb-commits] [PATCH] D72133: Data formatters: Look through array element typedefs

jarin marked 7 inline comments as done. jarin added a comment. I have addressed the comments, thanks for the quick review. Comment at: lldb/source/API/SBType.cpp:218 + return LLDB_RECORD_RESULT( + SBType(TypeImplSP(new TypeImpl(canonical_type.GetArrayElementType();

[Lldb-commits] [PATCH] D72133: Data formatters: Look through array element typedefs

jarin updated this revision to Diff 236021. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D72133/new/ https://reviews.llvm.org/D72133 Files: lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/array_typedef/Makefile

[Lldb-commits] [PATCH] D72133: Data formatters: Look through array element typedefs

jarin created this revision. jarin added a project: LLDB. Herald added a subscriber: lldb-commits. Motivation: When formatting an array of typedefed chars, we would like to display the array as a string. The string formatter currently does not trigger because the formatter lookup does not

[Lldb-commits] [PATCH] D69309: Support template instantiation in the expression evaluator

jarin added a comment. In D69309#1787481 , @labath wrote: > In D69309#1787468 , @jarin wrote: > > > What Fred proposes makes a lot of sense to me, although the lookup of > > instantiations might be slow because

[Lldb-commits] [PATCH] D69309: Support template instantiation in the expression evaluator

jarin added a comment. In D69309#1787409 , @labath wrote: > In D69309#1787297 , @jarin wrote: > > > In D69309#1752738 , @friss wrote: > > > > > Basically, today the debug

[Lldb-commits] [PATCH] D69309: Support template instantiation in the expression evaluator

jarin added a comment. In D69309#1752738 , @friss wrote: > Basically, today the debug info will describe an entity named "Foo". The > accelerator tables all reference this name. So when Clang asks us if we know > "Foo" (which is what happens when

[Lldb-commits] [PATCH] D69309: Support template instantiation in the expression evaluator

jarin added a comment. In D69309#1763454 , @v.g.vassilev wrote: > https://reviews.llvm.org/D41416 could be relevant. I am not an expert but I > think when reading the DWARF you could only register 'lazy' specializations > which will be imported only

[Lldb-commits] [PATCH] D69309: Support template instantiation in the expression evaluator

jarin added a comment. In D69309#1752738 , @friss wrote: > Sorry that I haven't reviewed the patch, but there's something I'd like to > point out before anyone invests a lot of time into plugin holes in our > current template support code. > > It would

[Lldb-commits] [PATCH] D69309: Support template instantiation in the expression evaluator

jarin updated this revision to Diff 230069. jarin added a comment. This update introduces a callback from clang for template specialization. The callback allows lldb to construct instantiations on demand, rather than having to create the instantiation eagerly. Perhaps it would still beneficial

[Lldb-commits] [PATCH] D69843: Expression eval lookup - prune methods without parsing

jarin added a comment. Thanks for the feedback! We will experiment with filtering in GetFunctions sometime next week. Regarding the FindTypes patch, it would be really nice to have that for Linux, as well. I see the type pruning (TypeMap::RemoveMismatchedTypes) taking several seconds for some

[Lldb-commits] [PATCH] D69309: Support template instantiation in the expression evaluator

jarin created this revision. Herald added subscribers: lldb-commits, arphaman, aprantl. Herald added a project: LLDB. WORK IN PROGRESS This change is mostly for discussion, it is messy and likely wrong as I am new to the lldb codebase. The goal of this exercise is to support expressions

[Lldb-commits] [PATCH] D68454: Fix the unwinding plan augmentation from x86 assembly

jarin added a comment. Thank you for the review! Could you also possibly commit the change for me? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68454/new/ https://reviews.llvm.org/D68454 ___

[Lldb-commits] [PATCH] D68454: Fix the unwinding plan augmentation from x86 assembly

jarin added a reviewer: labath. jarin added a comment. Pavel, could you possibly take a look? It looks like Jason is busy with something else... Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68454/new/ https://reviews.llvm.org/D68454

[Lldb-commits] [PATCH] D68454: Fix the unwinding plan augmentation from x86 assembly

jarin created this revision. Herald added a project: LLDB. Herald added a subscriber: lldb-commits. Unwind plan augmentation should compute the plan row at offset x from the instruction before offset x, but currently we compute it from the instruction at offset x. Note that this behavior is a

[Lldb-commits] [PATCH] D68278: Fix evaluation of nested classes with parent from other CU

jarin added inline comments. Comment at: packages/Python/lldbsuite/test/lang/cpp/nested-class-other-compilation-unit/TestNestedClassWithParentInAnotherCU.py:2 +""" +Test that expression evaluator can access members of nested classes even if +the parents of the nested classes

[Lldb-commits] [PATCH] D68278: Fix evaluation of nested classes with parent from other CU

jarin updated this revision to Diff 222803. jarin marked 5 inline comments as done. jarin added a comment. Fixed the nits, thanks for the careful review! I will indeed need someone to submit this for me. Thanks in advance :-) CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68278/new/

[Lldb-commits] [PATCH] D68278: Fix evaluation of nested classes with parent from other CU

jarin updated this revision to Diff 222757. jarin added a comment. Fixed a typo. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68278/new/ https://reviews.llvm.org/D68278 Files: packages/Python/lldbsuite/test/lang/cpp/nested-class-other-compilation-unit/Makefile

[Lldb-commits] [PATCH] D68278: Fix evaluation of nested classes with parent from other CU

jarin updated this revision to Diff 222756. jarin added a comment. I have added some comments to the test (I hope it is not too overboard), removed the LEVEL stuff from the Makefile and fixed the formatting. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68278/new/

[Lldb-commits] [PATCH] D68278: Fix evaluation of nested classes with parent from other CU

jarin created this revision. Herald added subscribers: lldb-commits, JDevlieghere, teemperor. Herald added a project: LLDB. This makes sure that we associate DIEs that are imported from other CUs with the appropriate decl context. Without this fix, nested classes can be dumped directly into

<    1   2