Re: [lldb-dev] Evaluating the same expression at the same breakpoint gets slower after a certain number of steps
Speaking more generally, can evaluating an expression with no side effects affect the outcome of subsequent evaluations? I.e, is it possible for the expression evaluation X to produce different results in the following scenarios? Scenario 1: Scenario 2: Thanks! On Tue, Jul 9, 2019 at 2:52 PM Guilherme Andrade wrote: > Thanks for looking into this, Jason. I ended up realizing that it isn't > about the number of evaluations; it is the exact location of the > breakpoints that matters. > > I'm being able to consistently reproduce this by having two breakpoints (A > and B) inside the same function, but B being inside the scope of a for loop > that defines a couple extra variables. The first evaluation of > 'undefinedVariable' at breakpoint A generates the following > FindExternalLexicalDecls calls: > > FindExternalLexicalDecls[5] on (ASTContext*)01566104F030 in 'Type0' > (CXXRecordDecl*)015668964438 > FindExternalLexicalDecls[6] on (ASTContext*)01566104F030 in 'Type6' > (CXXRecordDecl*)015668961BA8 > FindExternalLexicalDecls[7] on (ASTContext*)01566104F030 in 'Type7' > (CXXRecordDecl*)015668961A68 > FindExternalLexicalDecls[8] on (ASTContext*)01566104F030 in 'Type8' > (CXXRecordDecl*)015674F56208 > FindExternalLexicalDecls[9] on (ASTContext*)01566104F030 in 'Type9' > (ClassTemplateSpecializationDecl*)015674F56CD0 > FindExternalLexicalDecls[10] on (ASTContext*)01566104F030 in 'Type10' > (CXXRecordDecl*)015668964300 > FindExternalLexicalDecls[11] on (ASTContext*)01566104F030 in 'Type10' > (CXXRecordDecl*)015668964300 > FindExternalLexicalDecls[12] on (ASTContext*)01566104F030 in 'Type0' > (CXXRecordDecl*)015668964438 > FindExternalLexicalDecls[13] on (ASTContext*)01566104F030 in 'Type11' > (EnumDecl*)015674F62778 > > Then, the evaluation at breakpoint B generates: > > FindExternalLexicalDecls[19] on (ASTContext*)01F1F6275320 in 'Type0' > (CXXRecordDecl*)01F1EA798868 > FindExternalLexicalDecls[20] on (ASTContext*)01F1F6275320 in 'Type1' > (CXXRecordDecl*)01F1EA799098 > FindExternalLexicalDecls[21] on (ASTContext*)01F1F6275320 in 'Type2' > (ClassTemplateSpecializationDecl*)01F1EA7A0D50 > FindExternalLexicalDecls[22] on (ASTContext*)01F1F6275320 in 'Type3' > (CXXRecordDecl*)01F1EA79D818 > FindExternalLexicalDecls[23] on (ASTContext*)01F1F6275320 in 'Type4' > (CXXRecordDecl*)01F1EA79D548 > FindExternalLexicalDecls[24] on (ASTContext*)01F1F6275320 in 'Type5' > (CXXRecordDecl*)01F1EA7A2A08 > FindExternalLexicalDecls[25] on (ASTContext*)01F1F6275320 in 'Type6' > (CXXRecordDecl*)01F1EA7BB368 > FindExternalLexicalDecls[26] on (ASTContext*)01F1F6275320 in 'Type7' > (CXXRecordDecl*)01F1EA7BB228 > FindExternalLexicalDecls[27] on (ASTContext*)01F1F6275320 in 'Type8' > (CXXRecordDecl*)01F1F68B9088 > FindExternalLexicalDecls[28] on (ASTContext*)01F1F6275320 in 'Type9' > (ClassTemplateSpecializationDecl*)01F1F68B2AC0 > FindExternalLexicalDecls[29] on (ASTContext*)01F1F6275320 in 'Type10' > (CXXRecordDecl*)01F1EA798730 > FindExternalLexicalDecls[30] on (ASTContext*)01F1F6275320 in 'Type10' > (CXXRecordDecl*)01F1EA798730 > FindExternalLexicalDecls[31] on (ASTContext*)01F1F6275320 in 'Type0' > (CXXRecordDecl*)01F1EA798868 > FindExternalLexicalDecls[32] on (ASTContext*)01F1F6275320 in 'Type11' > (EnumDecl*)01F1F68CB3E0 > FindExternalLexicalDecls[33] on (ASTContext*)01F1F6275320 in 'Type12' > (CXXRecordDecl*)01F1E2351F48 > > And the subsequent evaluations at breakpoint A, which are slower, produce: > > FindExternalLexicalDecls[91] on (ASTContext*)01566104F030 in 'Type0' > (CXXRecordDecl*)01566895C3B8 > FindExternalLexicalDecls[92] on (ASTContext*)01566104F030 in 'Type1' > (CXXRecordDecl*)01566895CBE8 > FindExternalLexicalDecls[93] on (ASTContext*)01566104F030 in 'Type2' > (ClassTemplateSpecializationDecl*)0156689678D0 > FindExternalLexicalDecls[94] on (ASTContext*)01566104F030 in 'Type3' > (CXXRecordDecl*)015668964398 > FindExternalLexicalDecls[95] on (ASTContext*)01566104F030 in 'Type4' > (CXXRecordDecl*)0156689640C8 > FindExternalLexicalDecls[96] on (ASTContext*)01566104F030 in 'Type5' > (CXXRecordDecl*)015674F608B8 > FindExternalLexicalDecls[97] on (ASTContext*)01566104F030 in 'Type6' > (CXXRecordDecl*)015674F731B8 > FindExternalLexicalDecls[98] on (ASTContext*)01566104F030 in 'Type7' > (CXXRecordDecl*)015674F73078 > FindExternalLexicalDecls[99] on (ASTContext*)01566104F030 in 'Type8' > (CXXRecordDecl*)015674F7B278 > FindExternalLexicalDecls[100] on (ASTContext*)01566104F030 in 'Type9' > (ClassTemplateSpecializationDecl*)015674F78CF0 > FindExternalLexicalDecls[101] on (ASTContext*)01566104F030 in 'Type10' > (CXXRecordDecl*)01566895C280 > FindExternalLexicalDecls[102] on (ASTContext*)01566104F030 in 'Type10' > (CXXRecordDecl*)01566895C28
Re: [lldb-dev] Evaluating the same expression at the same breakpoint gets slower after a certain number of steps
lldb realizes types from DWARF lazily. So for instance, if an expression refers to a pointer to type Foo, we won't necessarily realize the full type of Foo from DWARF to parse that expression. Then if you write a second expression that accesses a member of an object of type Foo, we will realize the full type for Foo. Then if you run the first expression again, the pointer to Foo type in the lldb type system will now point to a realized type of Foo. That should not make any difference, since if we were right the first time that we didn't need to know anything about Foo, it shouldn't matter whether the full type is realized or not. Similarly, the "expression with no side effects" could have also caused lldb to realize any number of other types. We find names from type information in two ways: looking in the realized types, and looking in the name indexes we read from DWARF or (on systems without accelerator tables) from indexing the DWARF manually. So the expression with no side effects will change the types in the realized types pool. That also "should not matter" because if the expression X was looking up by name, the lookup through the name indexes when the type wasn't realized yet should be equivalent to the lookup in the realized types. We really have no choice but to realize types lazily in this way, the debugger would just run way too slowly on big projects if we didn't. So the fact that one expression can change the state of the type system for a subsequent expression is a fact of life for lldb. But if the lookup mechanism is working properly, then these changes shouldn't matter. OTOH shouldn't and don't are not quite the same... Jim > On Jul 11, 2019, at 9:53 AM, Guilherme Andrade wrote: > > Speaking more generally, can evaluating an expression with no side effects > affect the outcome of subsequent evaluations? I.e, is it possible for the > expression evaluation X to produce different results in the following > scenarios? > > Scenario 1: effects> > Scenario 2:evaluation X> > > Thanks! > > On Tue, Jul 9, 2019 at 2:52 PM Guilherme Andrade > wrote: > Thanks for looking into this, Jason. I ended up realizing that it isn't about > the number of evaluations; it is the exact location of the breakpoints that > matters. > > I'm being able to consistently reproduce this by having two breakpoints (A > and B) inside the same function, but B being inside the scope of a for loop > that defines a couple extra variables. The first evaluation of > 'undefinedVariable' at breakpoint A generates the following > FindExternalLexicalDecls calls: > > FindExternalLexicalDecls[5] on (ASTContext*)01566104F030 in 'Type0' > (CXXRecordDecl*)015668964438 > FindExternalLexicalDecls[6] on (ASTContext*)01566104F030 in 'Type6' > (CXXRecordDecl*)015668961BA8 > FindExternalLexicalDecls[7] on (ASTContext*)01566104F030 in 'Type7' > (CXXRecordDecl*)015668961A68 > FindExternalLexicalDecls[8] on (ASTContext*)01566104F030 in 'Type8' > (CXXRecordDecl*)015674F56208 > FindExternalLexicalDecls[9] on (ASTContext*)01566104F030 in 'Type9' > (ClassTemplateSpecializationDecl*)015674F56CD0 > FindExternalLexicalDecls[10] on (ASTContext*)01566104F030 in 'Type10' > (CXXRecordDecl*)015668964300 > FindExternalLexicalDecls[11] on (ASTContext*)01566104F030 in 'Type10' > (CXXRecordDecl*)015668964300 > FindExternalLexicalDecls[12] on (ASTContext*)01566104F030 in 'Type0' > (CXXRecordDecl*)015668964438 > FindExternalLexicalDecls[13] on (ASTContext*)01566104F030 in 'Type11' > (EnumDecl*)015674F62778 > > Then, the evaluation at breakpoint B generates: > > FindExternalLexicalDecls[19] on (ASTContext*)01F1F6275320 in 'Type0' > (CXXRecordDecl*)01F1EA798868 > FindExternalLexicalDecls[20] on (ASTContext*)01F1F6275320 in 'Type1' > (CXXRecordDecl*)01F1EA799098 > FindExternalLexicalDecls[21] on (ASTContext*)01F1F6275320 in 'Type2' > (ClassTemplateSpecializationDecl*)01F1EA7A0D50 > FindExternalLexicalDecls[22] on (ASTContext*)01F1F6275320 in 'Type3' > (CXXRecordDecl*)01F1EA79D818 > FindExternalLexicalDecls[23] on (ASTContext*)01F1F6275320 in 'Type4' > (CXXRecordDecl*)01F1EA79D548 > FindExternalLexicalDecls[24] on (ASTContext*)01F1F6275320 in 'Type5' > (CXXRecordDecl*)01F1EA7A2A08 > FindExternalLexicalDecls[25] on (ASTContext*)01F1F6275320 in 'Type6' > (CXXRecordDecl*)01F1EA7BB368 > FindExternalLexicalDecls[26] on (ASTContext*)01F1F6275320 in 'Type7' > (CXXRecordDecl*)01F1EA7BB228 > FindExternalLexicalDecls[27] on (ASTContext*)01F1F6275320 in 'Type8' > (CXXRecordDecl*)01F1F68B9088 > FindExternalLexicalDecls[28] on (ASTContext*)01F1F6275320 in 'Type9' > (ClassTemplateSpecializationDecl*)01F1F68B2AC0 > FindExternalLexicalDecls[29] on (ASTContext*)01F1F6275320 in 'Type10' > (CXXRecordDecl*)01F1EA798730 > FindExternalLexicalDecls[30] on
[lldb-dev] Reminder: SVN will be retired on Oct 21, 2019 -- Please migrate your workflows to github ASAP.
Hi, We are still on track to retire SVN and complete the transition to GitHub by Oct 21, 2019 (This year's US Dev Meeting). Even though this 3+ months away, it is very important that you begin to migrate your workflows to GitHub as soon as possible. For developers, this means using the git-llvm script to commit changes and for CI systems or other read-only use cases can begin fetching code directly from GitHub. I have created a migration status page, so you can track the progress of the migration: http://llvm.org/GitHubMigrationStatus.html There is also a link to instructions for how to use the git-llvm script for committing changes. If you would like to help with any of the TODOs on that page, please comment on the bugzilla associated with the task. Thanks, Tom ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
