Re: [lldb-dev] Identifying instructions that definitely access memory
Hi Tatyana,
Thank you for your reply! 🙂
If I understand correctly, TargetOpcode::G_{LOAD, STORE} do not cover x86’s mov
instructions (and other relevant instructions of both x86 the rest of supported
architectures) and such, which also access memory, however I will look into it
more.
Additionally, thank you for the suggestion regarding llvm-dev ―I will forward
my email to that list, too.
― Vangelis
> On 7 Nov 2019, at 13:49, Tatyana Krasnukha
> wrote:
>
> Hi Vangelis,
>
> Not sure this will help you, but you can try to compare
> llvm::MachineInstr::getOpcode() with TargetOpcode::G_LOAD and
> TargetOpcode::G_STORE if you can obtain a MachineInstr instance.
> It also may have sense to ask llvm-dev for a proper solution.
>
> From: lldb-dev On Behalf Of Vangelis
> Tsiatsianas via lldb-dev
> Sent: Tuesday, November 5, 2019 3:43 PM
> To: via lldb-dev
> Cc: Vangelis Tsiatsianas
> Subject: Re: [lldb-dev] Identifying instructions that definitely access memory
>
> Hello,
>
> I decided to try once more with a follow-up email, since my previous one got
> no responses (I hope it’s not considered rude to send more than one message
> in a row for a particular question).
>
> To sum up and clarify my previous question, what I need is a way to track
> memory stores and save both the old and the new value of the memory location
> being modified.
>
> My thinking so far:
> Recognize the instructions that definitely access memory before they execute,
> based on their opcode.
> Tell whether each operand is a register or a memory location.
> If it’s a memory location, check whether it is a load or store destination.
> In case it is a store destination, fetch and save current value from memory.
> Execute instruction.
> Fetch and save new value from memory.
>
> However, I was not able to find a cross-architecture API that covers all of
> the conditions above and more specifically Instruction::DoesStore() and
> Operand::IsStoreDestination().
>
> Last but not least, I should notice that the target is executed in
> single-step mode, so I do have control right before and after the execution
> of every instruction.
>
> Thanks, again, in advance! 🙂
>
>
> ― Vangelis
>
>
>
> On 21 Oct 2019, at 08:54, Vangelis Tsiatsianas > wrote:
>
> Hello,
>
> I am looking for a way to identify loads, stores and any other kind of
> instruction that definitely perform memory access and extract the address
> operand(s), however I was not able to find a cross-architecture API. The
> closest I stumbled upon are "MCInstrDesc::mayLoad()" and
> "MCInstrDesc::mayStore()", but I understand that their results are just a
> hint, so I would then need to examine the instruction name or opcode in order
> to find out whether it’s actually a load or store and which operand(s) is
> (are) memory address(es) and also do so for each architecture separately,
> which I would really like to avoid.
>
> Is there a way to identify such instructions either by examining them through
> the disassembler (e.g. "DoesLoad()" | "DoesStore()") before they execute or
> right after they perform any kind of memory access?
>
> Thank you very much, in advance! 🙂
>
>
> ― Vangelis
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] RFC: Using GitHub Actions for CI testing on the release/* branches
Although I've not had any Github Action experience, and despite being one who has raised objections to other parts of adopting github features, this sounds like a sensible idea. It seems odd to me that we don't already have some form of CI for our releases, so anything that improves on that is great. James On Tue, 12 Nov 2019 at 00:34, David Blaikie via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Not having given it deep thought/analysis, nor understanding much of the > GIT infrastructure here, but: Sounds good to me, for whatever that's worth > :) > > On Mon, Nov 11, 2019 at 4:32 PM Tom Stellard via llvm-dev < > llvm-...@lists.llvm.org> wrote: > >> Hi, >> >> I would like to start using GitHub Actions[1] for CI testing on the >> release/* >> branches. As far as I know we don't have any buildbots listening to the >> release branches, and I think GitHub Actions are a good way for us to >> quickly >> bring-up some CI jobs there. >> >> My proposal is to start by adding two post-commit CI jobs to the >> release/9.x branch. >> One for building and testing (ninja checka-all) llvm/clang/lld on Linux, >> Windows, and Mac, and another for detecting ABI changes since the 9.0.0 >> release. >> >> I have already implemented these two CI jobs in my llvm-project fork on >> GitHub[2][3], >> but in order to get these running in the main repository, I would need to: >> >> 1. Create a new repository in the LLVM organization called 'actions' for >> storing some custom >> builds steps for our CI jobs (see [4]). >> 2. Commit yaml CI definitions to the .github/workflows directory in the >> release/9.x >> branch. >> >> In the future, I would also like to add buil and tests jobs for other >> sub-projects >> once I am able to get those working. >> >> In addition to being used for post-commit testing, having these CI >> definitions in the >> main tree will make it easier for me (or anyone) to do pre-commit testing >> for the >> release branch in a personal fork. It will also allow me to experiment >> with some new >> workflows to help make managing the releases much easier. >> >> I think this will be a good way to test Actions in a low traffic >> environment to >> see if they are something we would want to use for CI on the master >> branch. >> >> Given that we are close to the end of the 9.0.1 cycle, unless there are >> any >> strong objections, I would like to get this enabled by Mon Nov 18, to >> maximize its >> usefulness. Let me know what you think. >> >> Thanks, >> Tom >> >> [1] https://github.com/features/actions >> [2] >> https://github.com/tstellar/llvm-project/commit/952d80e8509ecc95797b2ddbf1af40abad2dcf4e/checks?check_suite_id=305765621 >> [3] >> https://github.com/tstellar/llvm-project/commit/6d74f1b81632ef081dffa1e0c0434f47d4954423/checks?check_suite_id=303074176 >> [4] https://github.com/tstellar/actions >> >> ___ >> LLVM Developers mailing list >> llvm-...@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] RFC: Using GitHub Actions for CI testing on the release/* branches
Hi Tom, This sounds very interesting! +1 from me. What does this imply for the release testers? Would it be possible / desirable for us to add self-hosted runners for other architectures? I'm assuming GitHub only provides x86, right? I totally missed any details about that in their docs, but it seems to be implied here [1]. I'm not saying we should go all-possible-arches from the start, we can definitely try it out only for x86 this time around if you think that would be the best approach. Thanks, Diana [1] https://github.blog/2019-11-05-self-hosted-runners-for-github-actions-is-now-in-beta/ On Tue, 12 Nov 2019 at 10:33, James Henderson via lldb-dev wrote: > > Although I've not had any Github Action experience, and despite being one who > has raised objections to other parts of adopting github features, this sounds > like a sensible idea. It seems odd to me that we don't already have some form > of CI for our releases, so anything that improves on that is great. > > James > > On Tue, 12 Nov 2019 at 00:34, David Blaikie via lldb-dev > wrote: >> >> Not having given it deep thought/analysis, nor understanding much of the GIT >> infrastructure here, but: Sounds good to me, for whatever that's worth :) >> >> On Mon, Nov 11, 2019 at 4:32 PM Tom Stellard via llvm-dev >> wrote: >>> >>> Hi, >>> >>> I would like to start using GitHub Actions[1] for CI testing on the >>> release/* >>> branches. As far as I know we don't have any buildbots listening to the >>> release branches, and I think GitHub Actions are a good way for us to >>> quickly >>> bring-up some CI jobs there. >>> >>> My proposal is to start by adding two post-commit CI jobs to the >>> release/9.x branch. >>> One for building and testing (ninja checka-all) llvm/clang/lld on Linux, >>> Windows, and Mac, and another for detecting ABI changes since the 9.0.0 >>> release. >>> >>> I have already implemented these two CI jobs in my llvm-project fork on >>> GitHub[2][3], >>> but in order to get these running in the main repository, I would need to: >>> >>> 1. Create a new repository in the LLVM organization called 'actions' for >>> storing some custom >>> builds steps for our CI jobs (see [4]). >>> 2. Commit yaml CI definitions to the .github/workflows directory in the >>> release/9.x >>> branch. >>> >>> In the future, I would also like to add buil and tests jobs for other >>> sub-projects >>> once I am able to get those working. >>> >>> In addition to being used for post-commit testing, having these CI >>> definitions in the >>> main tree will make it easier for me (or anyone) to do pre-commit testing >>> for the >>> release branch in a personal fork. It will also allow me to experiment >>> with some new >>> workflows to help make managing the releases much easier. >>> >>> I think this will be a good way to test Actions in a low traffic >>> environment to >>> see if they are something we would want to use for CI on the master branch. >>> >>> Given that we are close to the end of the 9.0.1 cycle, unless there are any >>> strong objections, I would like to get this enabled by Mon Nov 18, to >>> maximize its >>> usefulness. Let me know what you think. >>> >>> Thanks, >>> Tom >>> >>> [1] https://github.com/features/actions >>> [2] >>> https://github.com/tstellar/llvm-project/commit/952d80e8509ecc95797b2ddbf1af40abad2dcf4e/checks?check_suite_id=305765621 >>> [3] >>> https://github.com/tstellar/llvm-project/commit/6d74f1b81632ef081dffa1e0c0434f47d4954423/checks?check_suite_id=303074176 >>> [4] https://github.com/tstellar/actions >>> >>> ___ >>> LLVM Developers mailing list >>> llvm-...@lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Slow expression evaluation (ASTImporter is too eager?)
Hi,
thanks for the feedback, I did some more investigation and now I understand
a bit better where the LayoutRecordType calls are coming from. They are
initiated by
Clang's code generation for types, which insists on generating full LLVM
types
for any complete RecordDecl (see
https://github.com/llvm-mirror/clang/blob/65acf43270ea2894dffa0d0b292b92402f80c8cb/lib/CodeGen/CodeGenTypes.cpp#L752
,
the bailout for incomplete record decls is at
https://github.com/llvm-mirror/clang/blob/master/lib/CodeGen/CodeGenTypes.cpp#L729
).
Ideally, clang would only emit forward declarations for any type that is
only
used as a pointer, but that is not the case at the moment. It is not quite
clear
what else we could do on the lldb side to prevent clang from emitting types
for all
those structs. At the end of this email, I am pasting a stack trace that
illustrates
the recursive emit for a pointer-chain of structs.
There is also one additional problem with importing base classes. This one
is perhaps
more related to AST importer. Again this is best illustrated with an
example.
struct F1 { int f1 = 30; };
struct F0 { int f0 = 31; };
struct B0 {
F0 b0f;
};
struct C0 : B0 {
};
struct B1 {
F1 b1f;
int f(C0* c0);
};
struct C1 : B1 {};
struct C2 { int x = 4; C1* c1 = 0; };
int main() {
C0 c0;
C1 c1;
C2 c2;
return 0; // break here
}
If we evaluate c2.x in lldb after evaluating c1 and c0, the AST importer
unnecessarily imports all the classes in this file. The main reason for
this is
that the import for structs needs to set the DefaultedDestructorIsConstexpr
bit, which is computed by looking at destructors of base classes. Looking at
the destructors triggers completion and import of the base classes, which in
turn might trigger more imports of base classes. In the example above,
importing C1 will cause completion and import of B1, which in turn causes
import of C0, and recursively completion and import of B0. Below is a
stack trace showing import of field F0::f0 from evaluation of c2.x. The
stack traces going through the
VisitRecordDecl-->ImportDefinition-->setBases path appear to be very hot
in the workloads we see (debugging large codebases). Below is a stack
trace that illustrates visiting F0::f0 from the evaluation of c2.x. The
question is what is the right place to break this long chain of imports.
Ideally, we would not have to import fields of C1 or B1 when evaluating
c2.x. Any ideas?
Stack trace visiting F0::f0 from eval of c2.x, I have tried to highlight
what is imported/completed where.
clang::ASTNodeImporter::VisitFieldDecl;; Visit F0::f0
clang::declvisitor::Base<...>::Visit
clang::ASTImporter::ImportImpl
lldb_private::ClangASTImporter::ASTImporterDelegate::ImportImpl
clang::ASTImporter::Import
lldb_private::ClangASTImporter::CopyDecl
lldb_private::ClangASTSource::CopyDecl
lldb_private::ClangASTSource::FindExternalLexicalDecls
lldb_private::ClangASTSource::ClangASTSourceProxy::FindExternalLexicalDecls
clang::ExternalASTSource::FindExternalLexicalDecls
clang::DeclContext::LoadLexicalDeclsFromExternalStorage const
clang::DeclContext::buildLookup ;; lookup destructor
of B0
clang::DeclContext::lookup const
clang::CXXRecordDecl::getDestructor const
clang::CXXRecordDecl::hasConstexprDestructor const
clang::CXXRecordDecl::addedClassSubobject
clang::CXXRecordDecl::addedMember
clang::DeclContext::addHiddenDecl
clang::DeclContext::addDeclInternal
clang::ASTNodeImporter::VisitFieldDecl;; visit B0::b0f
clang::declvisitor::Base<...>::Visit
clang::ASTImporter::ImportImpl
lldb_private::ClangASTImporter::ASTImporterDelegate::ImportImpl
clang::ASTImporter::Import
lldb_private::ClangASTImporter::CopyDecl
lldb_private::ClangASTSource::CopyDecl
lldb_private::ClangASTSource::FindExternalLexicalDecls
lldb_private::ClangASTSource::ClangASTSourceProxy::FindExternalLexicalDecls
clang::RecordDecl::LoadFieldsFromExternalStorage const
clang::RecordDecl::field_begin const
clang::RecordDecl::field_empty const ;; fields of B0
clang::CXXRecordDecl::setBases
clang::ASTNodeImporter::ImportDefinition
clang::ASTNodeImporter::VisitRecordDecl ;; visit C0
clang::declvisitor::Base<...>::VisitCXXRecordDecl
clang::declvisitor::Base<...>::Visit
clang::ASTImporter::ImportImpl
lldb_private::ClangASTImporter::ASTImporterDelegate::ImportImpl
clang::ASTImporter::Import
llvm::Expected
clang::ASTNodeImporter::import
clang::ASTNodeImporter::VisitRecordType
clang::TypeVisitor
>::Visit
clang::ASTImporter::Import
llvm::Expected
clang::ASTNodeImporter::import
clang::ASTNodeImporter::VisitPointerType ;; visit pointer to C0
clang::TypeVisitor
>::Visit
clang::ASTImporter::Import
llvm::Expected
clang::ASTNodeImporter::import
clang::ASTNodeImporter::VisitFunctionProtoType
clang::TypeVisitor
>::Visit
clang::ASTImporter::Import
llvm::Expected
clang::ASTNodeImporter::import
llvm::Expected<...> clang::ASTNodeImporter::importSeq<...>
clang::ASTNodeImporter::Vis
Re: [lldb-dev] RFC: Using GitHub Actions for CI testing on the release/* branches
On Tue, Nov 12, 2019 at 1:32 AM Tom Stellard via lldb-dev wrote: > > Hi, > > I would like to start using GitHub Actions[1] for CI testing on the release/* > branches. As far as I know we don't have any buildbots listening to the > release branches, and I think GitHub Actions are a good way for us to quickly > bring-up some CI jobs there. > > My proposal is to start by adding two post-commit CI jobs to the release/9.x > branch. > One for building and testing (ninja checka-all) llvm/clang/lld on Linux, > Windows, and Mac, and another for detecting ABI changes since the 9.0.0 > release. > > I have already implemented these two CI jobs in my llvm-project fork on > GitHub[2][3], > but in order to get these running in the main repository, I would need to: > > 1. Create a new repository in the LLVM organization called 'actions' for > storing some custom > builds steps for our CI jobs (see [4]). > 2. Commit yaml CI definitions to the .github/workflows directory in the > release/9.x > branch. > > In the future, I would also like to add buil and tests jobs for other > sub-projects > once I am able to get those working. > > In addition to being used for post-commit testing, having these CI > definitions in the > main tree will make it easier for me (or anyone) to do pre-commit testing for > the > release branch in a personal fork. It will also allow me to experiment with > some new > workflows to help make managing the releases much easier. > > I think this will be a good way to test Actions in a low traffic environment > to > see if they are something we would want to use for CI on the master branch. > > Given that we are close to the end of the 9.0.1 cycle, unless there are any > strong objections, I would like to get this enabled by Mon Nov 18, to > maximize its > usefulness. Let me know what you think. > > Thanks, > Tom > > [1] https://github.com/features/actions > [2] > https://github.com/tstellar/llvm-project/commit/952d80e8509ecc95797b2ddbf1af40abad2dcf4e/checks?check_suite_id=305765621 > [3] > https://github.com/tstellar/llvm-project/commit/6d74f1b81632ef081dffa1e0c0434f47d4954423/checks?check_suite_id=303074176 > [4] https://github.com/tstellar/actions Sounds great to me! ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] RFC: Using GitHub Actions for CI testing on the release/* branches
Hey Tom, That sounds really useful. Would it be possible to include LLDB as well? We have a subset of tests (unit & lit) that can be run without Python/SWIG by passing LLDB_DISABLE_PYTHON=ON to CMake. Thanks, Jonas On Tue, Nov 12, 2019 at 2:35 AM Hans Wennborg via cfe-dev wrote: > > On Tue, Nov 12, 2019 at 1:32 AM Tom Stellard via lldb-dev > wrote: > > > > Hi, > > > > I would like to start using GitHub Actions[1] for CI testing on the > > release/* > > branches. As far as I know we don't have any buildbots listening to the > > release branches, and I think GitHub Actions are a good way for us to > > quickly > > bring-up some CI jobs there. > > > > My proposal is to start by adding two post-commit CI jobs to the > > release/9.x branch. > > One for building and testing (ninja checka-all) llvm/clang/lld on Linux, > > Windows, and Mac, and another for detecting ABI changes since the 9.0.0 > > release. > > > > I have already implemented these two CI jobs in my llvm-project fork on > > GitHub[2][3], > > but in order to get these running in the main repository, I would need to: > > > > 1. Create a new repository in the LLVM organization called 'actions' for > > storing some custom > > builds steps for our CI jobs (see [4]). > > 2. Commit yaml CI definitions to the .github/workflows directory in the > > release/9.x > > branch. > > > > In the future, I would also like to add buil and tests jobs for other > > sub-projects > > once I am able to get those working. > > > > In addition to being used for post-commit testing, having these CI > > definitions in the > > main tree will make it easier for me (or anyone) to do pre-commit testing > > for the > > release branch in a personal fork. It will also allow me to experiment > > with some new > > workflows to help make managing the releases much easier. > > > > I think this will be a good way to test Actions in a low traffic > > environment to > > see if they are something we would want to use for CI on the master branch. > > > > Given that we are close to the end of the 9.0.1 cycle, unless there are any > > strong objections, I would like to get this enabled by Mon Nov 18, to > > maximize its > > usefulness. Let me know what you think. > > > > Thanks, > > Tom > > > > [1] https://github.com/features/actions > > [2] > > https://github.com/tstellar/llvm-project/commit/952d80e8509ecc95797b2ddbf1af40abad2dcf4e/checks?check_suite_id=305765621 > > [3] > > https://github.com/tstellar/llvm-project/commit/6d74f1b81632ef081dffa1e0c0434f47d4954423/checks?check_suite_id=303074176 > > [4] https://github.com/tstellar/actions > > Sounds great to me! > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] RFC: Using GitHub Actions for CI testing on the release/* branches
On 11/12/2019 10:03 AM, Jonas Devlieghere wrote: > Hey Tom, > > That sounds really useful. Would it be possible to include LLDB as > well? We have a subset of tests (unit & lit) that can be run without > Python/SWIG by passing LLDB_DISABLE_PYTHON=ON to CMake. > I can try to add an lldb builder. Would you be able to provide me with the cmake arguments plus a check target where all tests are expected to pass? Thanks, Tom > Thanks, > Jonas > > On Tue, Nov 12, 2019 at 2:35 AM Hans Wennborg via cfe-dev > wrote: >> >> On Tue, Nov 12, 2019 at 1:32 AM Tom Stellard via lldb-dev >> wrote: >>> >>> Hi, >>> >>> I would like to start using GitHub Actions[1] for CI testing on the >>> release/* >>> branches. As far as I know we don't have any buildbots listening to the >>> release branches, and I think GitHub Actions are a good way for us to >>> quickly >>> bring-up some CI jobs there. >>> >>> My proposal is to start by adding two post-commit CI jobs to the >>> release/9.x branch. >>> One for building and testing (ninja checka-all) llvm/clang/lld on Linux, >>> Windows, and Mac, and another for detecting ABI changes since the 9.0.0 >>> release. >>> >>> I have already implemented these two CI jobs in my llvm-project fork on >>> GitHub[2][3], >>> but in order to get these running in the main repository, I would need to: >>> >>> 1. Create a new repository in the LLVM organization called 'actions' for >>> storing some custom >>> builds steps for our CI jobs (see [4]). >>> 2. Commit yaml CI definitions to the .github/workflows directory in the >>> release/9.x >>> branch. >>> >>> In the future, I would also like to add buil and tests jobs for other >>> sub-projects >>> once I am able to get those working. >>> >>> In addition to being used for post-commit testing, having these CI >>> definitions in the >>> main tree will make it easier for me (or anyone) to do pre-commit testing >>> for the >>> release branch in a personal fork. It will also allow me to experiment >>> with some new >>> workflows to help make managing the releases much easier. >>> >>> I think this will be a good way to test Actions in a low traffic >>> environment to >>> see if they are something we would want to use for CI on the master branch. >>> >>> Given that we are close to the end of the 9.0.1 cycle, unless there are any >>> strong objections, I would like to get this enabled by Mon Nov 18, to >>> maximize its >>> usefulness. Let me know what you think. >>> >>> Thanks, >>> Tom >>> >>> [1] https://github.com/features/actions >>> [2] >>> https://github.com/tstellar/llvm-project/commit/952d80e8509ecc95797b2ddbf1af40abad2dcf4e/checks?check_suite_id=305765621 >>> [3] >>> https://github.com/tstellar/llvm-project/commit/6d74f1b81632ef081dffa1e0c0434f47d4954423/checks?check_suite_id=303074176 >>> [4] https://github.com/tstellar/actions >> >> Sounds great to me! >> ___ >> cfe-dev mailing list >> cfe-...@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
