If we want to add a testsuite runner which takes a source file, a place to put
a breakpoint, the name of a variable to examine, and it runs through those in
SB API, I'm all in favor. I don't know if that's going to add a lot of test
coverage to lldb, but I have no problem with such a thing.
My
It's great to make writing tests easier. We'd all love to have more tests.
If "writing tests easier" is "command line output scraping", that's only
hurting the project in the long term. I'm telling you this from years of
experience on a project where we did exactly this. It's great to have ex
Also, sb api and command line test are neither mutually exclusive nor the
only 2 options.
Sean mentioned the idea of a dsl for example. I mentioned the idea of a
command that is independent of the normal ui command line.
There are lots of possibilities if you look.
Also our current situation is
There's also a cost to *not* writing test cases, which is paid
proportionally to how difficult it is to write test cases.
That said, aren't the existing lldbinline tests an example of the behavior
you're objecting to? And that is a relatively recent addition which I have
never seen or heard of any
On Sep 14, 2016, at 5:13 PM, Zachary Turner wrote:
> I don't blame you for being scared of command tests. I don't support their
> use in the current LLDB test suite either, for exactly the same reasons you
> and Jason have expressed. But I do think it's possible to come up with
> something
zturner accepted this revision.
zturner added a comment.
lgtm from my point of view after `LLDB_TEST_CXX_COMPILER` and
`LLDB_TEST_C_COMPILER` are added.
One question: Currently the tests appear to run all commands until the end of
the file, and then do 1 pass over the output through `FileCheck`
Author: jingham
Date: Wed Sep 14 20:47:22 2016
New Revision: 281569
URL: http://llvm.org/viewvc/llvm-project?rev=281569&view=rev
Log:
Make the keys enumerations for options and resolvers enum classes.
This keeps them from conflicting with other symbols names, so it's
worth their being less conven
I actually like the idea of feeding command lines. Again, not when the
command you're running prints a huge block of text and you try to match it.
But for "get the debugger into the state where i can reproduce the bug",
and sometimes the step to actually repro it, I think it's hands down the
best.
I agree completely with tackling the easy stuff first.
That said, the easy stuff (probably >50% of the testsuite) doesn't even require
command-line interaction and is just of the form "stop here, run this one
expression, maybe print this variable using 'frame variab'e'"
I would argue that we can
I agree that if all the tests look like the ones in this review there will
be no way to test 100% of the things we currently test. At the same time,
I see this as just a beginning. A replacement for lldbinline but one which
is more extensible. To test things like you said like multi-threaded
ste
> On Sep 14, 2016, at 5:13 PM, Zachary Turner wrote:
>
> I'm only saying that we should have an open mind. Obviously there are
> (valid!) concerns. If we can't solve them then we can't solve them. The
> goal (my goal anyway) is always to make things better, not to use X because
> it's X.
Also, you mentioned that this is very similar to the lldbinline tests. For
that reason, I would actually propose dropping lldbinline tests in favor of
this. If they are essentially the same, then it seems better to have 2
types of tests rather than 3, and it seems better for those 2 to be lit +
p
I'm only saying that we should have an open mind. Obviously there are
(valid!) concerns. If we can't solve them then we can't solve them. The
goal (my goal anyway) is always to make things better, not to use X because
it's X. There's value in consistency, but that doesn't mean that the value
fr
> On Sep 14, 2016, at 3:51 PM, Zachary Turner wrote:
>
> zturner added a comment.
>
> Also, it occurred to me that if all tests were like this (and yes, that's a
> tall order to imagine a world where not a single test was written using the
> Python API), we could probably actually drop the Py
Also, w.r.t:
> Aside from write imperative control flow constructs, which I see as a
> positive rather than a negative.
I wrote a bunch of tests to test that stepping behavior for swift and C was
reasonable. When stepping through source code, there is not one correct way to
write the line ta
You can get thing 1, thing 2, and thing 3 in declarative ways with a
command line api too. Like the example I gave earlier:
(lldb) print-dev threads[3].id
0x1234
(lldb) print-dev threads[4].id
0x2345
You're getting one value at a time, not a space separated list. Although I
think we could take
> On Sep 14, 2016, at 3:56 PM, Chris Bieneman wrote:
>
> @jingham and @zturner, we can also take advantage of FileCheck's use of
> regular expressions to write robust matchers. In general LLVM has managed to
> change text output formats many times in radical ways, and LIT's testing has
> stil
If the internal thing is three things in a list, you get back thing one, thing
two and thing three in declarative ways rather than "I got three space
separated things, maybe they had spaces in them, maybe there were quotes, etc,
and don't ever change this now or you'll have to go fix all the tes
On Wed, Sep 14, 2016 at 4:39 PM Jim Ingham wrote:
>
> > 4. You can test a LOT more things when you are able to use an api that
> doesn't have to be stable.
>
> When I mentioned that API, I had in mind an internal Python module that
> you could use to grub into internals. I'm all for that. I'm n
> On Sep 14, 2016, at 4:00 PM, Zachary Turner wrote:
>
> On Wed, Sep 14, 2016 at 3:51 PM Sean Callanan wrote:
> How different is that really from
>
> (lldb) script lldb.frame.FindVariable("argc").GetValue()
> '1'
> (lldb) script lldb.process.GetNumThreads()
> 1
> (lldb) script lldb.process.Get
zturner added inline comments.
Comment at: lit/CMakeLists.txt:14
@@ -13,1 +13,3 @@
+option(LLDB_TEST_CLANG "Use in-tree clang when testing lldb" Off)
+
beanz wrote:
> zturner wrote:
> > beanz wrote:
> > > Disallowing setting both seems reasonable to me. I'm not
beanz added a comment.
@zturner, we can absolutely add flags into the substitutions. Other projects do
that too.
Comment at: lit/CMakeLists.txt:14
@@ -13,1 +13,3 @@
+option(LLDB_TEST_CLANG "Use in-tree clang when testing lldb" Off)
+
zturner wrote:
> beanz wr
On Wed, Sep 14, 2016 at 4:28 PM Jason Molenda wrote:
> I have to concur with Jim's point -- writing & maintaining the gdb
> testsuite for years, which was based on commands & expected output like
> these lit tests, was a huge drag on everyone's productivity as the debugger
> changed over time. T
zturner added a comment.
One more question: Is there a way in lit that we can append command line flags
to the run lines even if the user doesn't specify them? For example in the
substitution?
For example, if someone writes `# RUN: %cxx %p/Inputs/call-function.cpp -g -o
%t && %lldb -b -s %s -
I have to concur with Jim's point -- writing & maintaining the gdb testsuite
for years, which was based on commands & expected output like these lit tests,
was a huge drag on everyone's productivity as the debugger changed over time.
This style of test looks wonderfully easy to read & write & d
beanz added inline comments.
Comment at: lit/CMakeLists.txt:14
@@ -13,1 +13,3 @@
+option(LLDB_TEST_CLANG "Use in-tree clang when testing lldb" Off)
+
Disallowing setting both seems reasonable to me. I'm not entirely sure how to
connect `LLDB_TEST_COMPILER` up i
zturner added inline comments.
Comment at: lit/CMakeLists.txt:14
@@ -13,1 +13,3 @@
+option(LLDB_TEST_CLANG "Use in-tree clang when testing lldb" Off)
+
beanz wrote:
> The `LLDB_TEST_COMPILER` option doesn't signify that it is using an in-tree
> or out-of-tree c
zturner added a comment.
Todd probably knows about this since he added the gtest target to the Xcode
project. I imagine there's a python test suite target and a gtest target.
Isn't it possible to have a third target which when you build it, builds the
other two targets (which would run the te
beanz added a comment.
@granata.enrico, it seems to me that this is a problem the people maintaining
the Xcode project should address. I know it is possible to create targets in
Xcode projects that call shell commands or makefiles (CMake does this). It is
therefore possible that the Xcode proje
beanz updated this revision to Diff 71460.
beanz added a comment.
- Use lit.util.which instead of constructing paths, which adds exe suffixes and
uses proper path seperators
- Fixed spelling error in list(APPEND ...) command
https://reviews.llvm.org/D24591
Files:
lit/CMakeLists.txt
lit/Exp
On Wed, Sep 14, 2016 at 4:00 PM Zachary Turner wrote:
>
> 4. You can test a LOT more things when you are able to use an api that
> doesn't have to be stable.
>
Regarding this point specifically, I think in the past Jim has even floated
the idea of having a "private API" that doesn't have to be s
On Wed, Sep 14, 2016 at 3:51 PM Sean Callanan wrote:
> How different is that really from
>
> (lldb) script lldb.frame.FindVariable("argc").GetValue()
> '1'
> (lldb) script lldb.process.GetNumThreads()
> 1
> (lldb) script lldb.process.GetThreadAtIndex(0).GetThreadID()
> 3514809
>
> ? If it's deve
granata.enrico added a comment.
In https://reviews.llvm.org/D24591#543277, @beanz wrote:
> @granata.enrico, we could migrate the existing tests into being executed by
> lit even if they aren't using lit's features, so if that direction is desired
> we could get everything in lit. That said, you
beanz added a comment.
@zturner, on many of your comments I need to do some research and get back to
you. Particularly I need to understand how lit works on Windows better. I do
have one inline response.
@granata.enrico, we could migrate the existing tests into being executed by lit
even if th
zturner added a comment.
Also, it occurred to me that if all tests were like this (and yes, that's a
tall order to imagine a world where not a single test was written using the
Python API), we could probably actually drop the Python 3.5 requirement on
Windows.
Another thing that's nice about t
How different is that really from
(lldb) script lldb.frame.FindVariable("argc").GetValue()
'1'
(lldb) script lldb.process.GetNumThreads()
1
(lldb) script lldb.process.GetThreadAtIndex(0).GetThreadID()
3514809
? If it's developer-only, then this is even fairly well-documented using e.g.
"script
zturner added a comment.
In https://reviews.llvm.org/D24591#543242, @jingham wrote:
> Writing tests this way means we're going back to testing the command line
> commands. That was what gdb did for the most part, and you ended up
> terrified of making changes that might effect command output,
jingham added a comment.
Writing tests this way means we're going back to testing the command line
commands. That was what gdb did for the most part, and you ended up terrified
of making changes that might effect command output, not because the change was
hard but because knew you would have t
granata.enrico added a subscriber: granata.enrico.
granata.enrico added a comment.
One piece of concern that I have is the multiplication of things that "testing
LLDB" means.
We have unit tests, Python tests, and now LIT tests.
That means, for each change I want to commit, if I want confidence
beanz updated this revision to Diff 71452.
beanz added a comment.
Added lldb-server as a test dependency based on feedback from @tfiala.
https://reviews.llvm.org/D24591
Files:
lit/CMakeLists.txt
lit/Expr/Inputs/anonymous-struct.cpp
lit/Expr/Inputs/call-function.cpp
lit/Expr/TestCallStdS
tfiala added a comment.
One other items we discussed that is sure to come up:
- Right now this is geared towards one compile per .test file (similar to
something Zachary brought up before). One way we could get the multiple debug
info formats handled is to have a .test for each of the formats,
zturner added a comment.
Couple questions:
1. What is the status of lit and Python 3? Running the test suite on Windows
**requires** Python 3.5+, so if we want this to work on Windows, we will need
to make sure the lit infrastructure is compatible with Python 3.
Comment at:
spyffe added a subscriber: spyffe.
spyffe added a comment.
I like this concept a lot, and I think it's great for testcases that actually
need to interact with the command line.
I'm concerned, though, that the separation of input from command files makes
tests more complex to write. One thing th
tfiala accepted this revision.
tfiala added a comment.
This revision is now accepted and ready to land.
Assuming this doesn't break anybody, this LGTM.
https://reviews.llvm.org/D24591
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://
tfiala added inline comments.
Comment at: lit/CMakeLists.txt:14
@@ -13,1 +13,3 @@
+option(LLDB_TEST_CLANG "Use in-tree clang when testing lldb" Off)
+
tfiala wrote:
> The macOS bots (and all the Swift ones) build with in-tree clang. I'm glad
> to have this opt
tfiala added a comment.
Looks like a nice start. Thanks for pulling this together, Chris!
Comment at: lit/CMakeLists.txt:14
@@ -13,1 +13,3 @@
+option(LLDB_TEST_CLANG "Use in-tree clang when testing lldb" Off)
+
The macOS bots (and all the Swift ones) build wi
zturner added a comment.
Huh... This is a surprise. Looking forward to reviewing this.
https://reviews.llvm.org/D24591
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
beanz created this revision.
beanz added reviewers: zturner, labath, jingham, tfiala.
beanz added a subscriber: lldb-commits.
Herald added subscribers: mgorny, beanz.
This patch supplies basic infrastructure for LLDB to use LIT, and ports a few
basic test cases from the LLDB test suite into LIT.
Author: spyffe
Date: Wed Sep 14 16:54:28 2016
New Revision: 281545
URL: http://llvm.org/viewvc/llvm-project?rev=281545&view=rev
Log:
More cleanup in `frame diagnose,` eliminating a bunch of messy cases.
Modified:
lldb/trunk/include/lldb/Core/Disassembler.h
lldb/trunk/source/Core/Disassemb
Yea, it's too bad about the type. This is one case where auto isn't just
syntactic sugar, it's actually necessary.
On Wed, Sep 14, 2016 at 2:07 PM Sean Callanan via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Author: spyffe
> Date: Wed Sep 14 15:58:31 2016
> New Revision: 281536
>
> URL
Author: spyffe
Date: Wed Sep 14 15:58:31 2016
New Revision: 281536
URL: http://llvm.org/viewvc/llvm-project?rev=281536&view=rev
Log:
Replaced two instances of std::function with auto.
Thanks to Zachary Turner for the suggestion. It's distasteful that the actual
type of the lambda can't be spelle
Okay, one sec.
Sean
> On Sep 14, 2016, at 1:40 PM, Zachary Turner wrote:
>
>
>
> On Wed, Sep 14, 2016 at 1:38 PM Sean Callanan via lldb-commits
> mailto:lldb-commits@lists.llvm.org>> wrote:
>
> Instruction::Operand *origin_operand = nullptr;
> -if (operands[0].m_type == Instruction
On Wed, Sep 14, 2016 at 1:38 PM Sean Callanan via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
>
> Instruction::Operand *origin_operand = nullptr;
> -if (operands[0].m_type == Instruction::Operand::Type::Register &&
> -operands[0].m_clobbered == true && operands[0].m_registe
Author: spyffe
Date: Wed Sep 14 15:29:57 2016
New Revision: 281534
URL: http://llvm.org/viewvc/llvm-project?rev=281534&view=rev
Log:
Cleaned up a little bit of redundant code in 'frame diagnose.`
Modified:
lldb/trunk/source/Target/StackFrame.cpp
Modified: lldb/trunk/source/Target/StackFrame.
Author: valentinagiusti
Date: Wed Sep 14 15:12:12 2016
New Revision: 281528
URL: http://llvm.org/viewvc/llvm-project?rev=281528&view=rev
Log:
Use 'enum class' instead of 'enum' in NativeRegisterContextLinux_x86_x64.
Reviewers: labath, clayborg, zturner
Subscribers: lldb-commits
Differential Rev
This revision was automatically updated to reflect the committed changes.
Closed by commit rL281528: Use 'enum class' instead of 'enum' in
NativeRegisterContextLinux_x86_x64. (authored by valentinagiusti).
Changed prior to commit:
https://reviews.llvm.org/D24578?vs=71412&id=71418#toc
Repositor
zturner accepted this revision.
zturner added a comment.
This revision is now accepted and ready to land.
Thanks!
https://reviews.llvm.org/D24578
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinf
Sorry I didn’t see your comments on the web interface, I’ll submit a followup
patch with these changes.
From: Zachary Turner [mailto:ztur...@google.com]
Sent: Wednesday, September 14, 2016 7:47 PM
To: Giusti, Valentina ; lldb-commits@lists.llvm.org
Subject: Re: [Lldb-commits] [lldb] r281507 - Use
Author: jingham
Date: Wed Sep 14 14:07:35 2016
New Revision: 281520
URL: http://llvm.org/viewvc/llvm-project?rev=281520&view=rev
Log:
Add SB API's for writing breakpoints to & creating the from a file.
Moved the guts of the code from CommandObjectBreakpoint to Target (should
have done it that way
Author: jingham
Date: Wed Sep 14 14:05:27 2016
New Revision: 281519
URL: http://llvm.org/viewvc/llvm-project?rev=281519&view=rev
Log:
Fix some const-ness issues with BreakpointID & BreakpointIDList.
Modified:
lldb/trunk/include/lldb/Breakpoint/BreakpointID.h
lldb/trunk/include/lldb/Breakp
wallace updated this revision to Diff 71409.
wallace added a comment.
rebase
https://reviews.llvm.org/D24284
Files:
source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.h
Index: source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.h
=
wallace updated this revision to Diff 71407.
wallace added a comment.
fix pointers
https://reviews.llvm.org/D24284
Files:
source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.h
Index: source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.h
===
Can probably do the same for XStateType as well:
enum class XStateType { Invalid, FXSAVE, XSAVE };
On Wed, Sep 14, 2016 at 10:46 AM Zachary Turner wrote:
> On Wed, Sep 14, 2016 at 10:36 AM Valentina Giusti via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>
>
On Wed, Sep 14, 2016 at 10:36 AM Valentina Giusti via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
>
> ==
> ---
> lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.h
> (original)
> +++
> lldb/
This revision was automatically updated to reflect the committed changes.
Closed by commit rL281507: Use Intel CPU flags to determine target supported
features. (authored by valentinagiusti).
Changed prior to commit:
https://reviews.llvm.org/D24559?vs=71371&id=71390#toc
Repository:
rL LLVM
Author: valentinagiusti
Date: Wed Sep 14 12:27:48 2016
New Revision: 281507
URL: http://llvm.org/viewvc/llvm-project?rev=281507&view=rev
Log:
Use Intel CPU flags to determine target supported features.
Summary:
This patch uses the instruction CPUID to verify that FXSAVE, XSAVE, AVX
and MPX are su
tfiala added inline comments.
Comment at:
packages/Python/lldbsuite/test/functionalities/load_unload/TestLoadUnload.py:163
@@ +162,3 @@
+# mixed in with stop locations.
+self.dbg.SetUseColor(False)
+
Upon further reflection, there is a logically m
tfiala added a comment.
Greg had a few pieces of feedback as well that we just discussed:
- Change the on/off switch for column marking to support the following states:
- terminal-code-only (i.e. only do terminal code highlighting, not the text
caret)
- terminal-code + text caret
- text ca
Can you still make the enum an enum class?
On Wed, Sep 14, 2016 at 9:07 AM Valentina Giusti via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> valentinagiusti updated this revision to Diff 71371.
> valentinagiusti added a comment.
>
> moved header to the bottom and moved enum into header fil
valentinagiusti updated this revision to Diff 71371.
valentinagiusti added a comment.
moved header to the bottom and moved enum into header file
https://reviews.llvm.org/D24559
Files:
source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
source/Plugins/Process/Linux/NativeRegis
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.
Looks good.
https://reviews.llvm.org/D24514
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/l
valentinagiusti marked 2 inline comments as done.
valentinagiusti added a comment.
This fixes the fact that there is no proper check that the kernel or the
hardware are actually supporting either AVX or MPX. Before this patch, the code
only relied on a "hack" that checks if it's possible to do a
labath added a comment.
I have to admit I have very little knowledge of this part of the code. Could
you provide a bit of a high-level overview of this change? Does this fix an
existing problem ? (If so, should it have a test?) Or is it just a refactor?
Comment at:
source/Plu
tfiala added a comment.
In https://reviews.llvm.org/D20835#541901, @jingham wrote:
> See inlined comments. Otherwise this is great.
Great, I'll fix those up. I like the command-line option idea.
https://reviews.llvm.org/D20835
___
lldb-commits
labath added a comment.
Thanks for adding the test case. LGTM from my side.
https://reviews.llvm.org/D24514
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
tberghammer updated this revision to Diff 71316.
tberghammer added a comment.
Adding a new test case
https://reviews.llvm.org/D24514
Files:
packages/Python/lldbsuite/test/python_api/symbol-context/two-files/TestSymbolContextTwoFiles.py
packages/Python/lldbsuite/test/python_api/symbol-conte
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
lgtm. In general, feel free to manage mips decorators as you see fit.
https://reviews.llvm.org/D24549
___
lldb-commits mailing list
lldb-commits@
nitesh.jain created this revision.
nitesh.jain added reviewers: clayborg, labath.
nitesh.jain added subscribers: jaydeep, bhushan, slthakur, lldb-commits.
These test cases tries to insert breakpoint in atomic sequence and cause atomic
sequence to restart when breakpoint is hit .
https://reviews
labath added a comment.
Looks straight-forward enough. However, it could use a test-case.
https://reviews.llvm.org/D24514
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
79 matches
Mail list logo
