labath added a comment.
In https://reviews.llvm.org/D42281#989793, @aprantl wrote:
> I am now working on building each test variant (dwarf,dwo,dsym,...) in its
> own build directory so they can run in parallel and we can get rid of the
> lockfile.
Are you planning to merge that into this patc
labath added a comment.
Thanks for the clarification. It seems nobody was calling that function, so
maybe it never actually worked.
I'll try committing this for Owen with the clang paths modified and check
whether the bots like it.
https://reviews.llvm.org/D42195
__
Author: labath
Date: Mon Jan 29 02:02:40 2018
New Revision: 323636
URL: http://llvm.org/viewvc/llvm-project?rev=323636&view=rev
Log:
[lldb] Generic base for testing gdb-remote behavior
Summary:
Adds new utilities that make it easier to write test cases for lldb acting as a
client over a gdb-remo
This revision was automatically updated to reflect the committed changes.
Closed by commit rL323636: [lldb] Generic base for testing gdb-remote behavior
(authored by labath, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D42195?vs=1313
Author: labath
Date: Mon Jan 29 02:46:00 2018
New Revision: 323637
URL: http://llvm.org/viewvc/llvm-project?rev=323637&view=rev
Log:
Remove ObjectFile usage from HostLinux::GetProcessInfo
Summary:
The ObjectFile class was used to determine the architecture of a running
process by inspecting it's
This revision was automatically updated to reflect the committed changes.
Closed by commit rL323637: Remove ObjectFile usage from
HostLinux::GetProcessInfo (authored by labath, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D42488?vs=1
Author: labath
Date: Mon Jan 29 03:10:21 2018
New Revision: 323639
URL: http://llvm.org/viewvc/llvm-project?rev=323639&view=rev
Log:
Fix NetBsd build broken by r323637
Modified:
lldb/trunk/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp
Modified: lldb/trunk/source/Plugins/Process/NetBS
tberghammer added a comment.
Thanks for the explanation, sorry I haven't read your commit message carefully.
In case of non-split-dwarf a die_offset is sufficient to uniquely identify a
DIE because it is an offset from the beginning of the debug_info section (we
assume we have at most 1 debug_i
omtcyfz added a comment.
@asmith Thanks!
@davide Thanks for the input!
I'll be able to do land it since I have commit access, thanks!
https://reviews.llvm.org/D42620
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cg
This revision was automatically updated to reflect the committed changes.
Closed by commit rL323645: [lldb] Silence signed <-> unsigned integer
comparison warning (authored by omtcyfz, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D42
labath added a comment.
I haven't gotten around to trying this out on windows yet, but I have tried
running the tests remotely. I've updated https://reviews.llvm.org/D42572 with
the two fixes necessary to make the remote tests pass (for android).
https://reviews.llvm.org/D42281
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
We have one plugin in-tree (tools/intel-features), but I'm not sure if anyone
uses/installs it.
In any case, the change seems like the right thing to do.
https://reviews.llvm.org/D42317
_
clayborg added inline comments.
Comment at: source/Host/linux/HostInfoLinux.cpp:208
bool HostInfoLinux::ComputeSystemPluginsDirectory(FileSpec &file_spec) {
- FileSpec temp_file("/usr/lib/lldb/plugins", true);
+ FileSpec temp_file("/usr/lib" LLDB_LIBDIR_SUFFIX "/lldb/plugins",
clayborg added a comment.
See inlined comment
https://reviews.llvm.org/D42317
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
mgorny added inline comments.
Comment at: source/Host/linux/HostInfoLinux.cpp:208
bool HostInfoLinux::ComputeSystemPluginsDirectory(FileSpec &file_spec) {
- FileSpec temp_file("/usr/lib/lldb/plugins", true);
+ FileSpec temp_file("/usr/lib" LLDB_LIBDIR_SUFFIX "/lldb/plugins", t
Any chance of using unique_ptr or other RAII/etc ownership to make this API
safer by default?
On Mon, Jan 22, 2018 at 10:58 AM Raphael Isemann via Phabricator via
llvm-commits wrote:
> This revision was not accepted when it landed; it landed in state "Needs
> Review".
> This revision was automat
On Mon, Jan 29, 2018 at 9:42 AM, David Blaikie via lldb-commits
wrote:
> Any chance of using unique_ptr or other RAII/etc ownership to make this API
> safer by default?
>
I agree that would be a more robust way of dealing with the problem.
Thanks,
--
Davide
_
> On Jan 28, 2018, at 9:59 PM, Davide Italiano wrote:
>
> On Thu, Jan 11, 2018 at 5:26 PM, Davide Italiano
> wrote:
>> On Thu, Jan 11, 2018 at 5:16 PM, Jason Molenda via lldb-commits
>> wrote:
>>> Author: jmolenda
>>> Date: Thu Jan 11 17:16:13 2018
>>> New Revision: 322339
>>>
>>> URL: http
clayborg accepted this revision.
clayborg added a comment.
Looks good.
https://reviews.llvm.org/D42317
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
aprantl added a comment.
In https://reviews.llvm.org/D42281#990296, @labath wrote:
> In https://reviews.llvm.org/D42281#989793, @aprantl wrote:
>
> > I am now working on building each test variant (dwarf,dwo,dsym,...) in its
> > own build directory so they can run in parallel and we can get rid
This revision was automatically updated to reflect the committed changes.
Closed by commit rL323673: [Host] Respect LLVM_LIBDIR_SUFFIX when looking for
LLDB plugins on Linux (authored by mgorny, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.ll
Author: mgorny
Date: Mon Jan 29 10:25:06 2018
New Revision: 323673
URL: http://llvm.org/viewvc/llvm-project?rev=323673&view=rev
Log:
[Host] Respect LLVM_LIBDIR_SUFFIX when looking for LLDB plugins on Linux
Fix the Linux plugin lookup path to include appropriate libdir suffix
for the system. To ac
vsk added a comment.
What's the failure mode? Have we had any issues with this on the bots?
Generally I'm all for removing flaky tests, I'd like to understand what makes
this flaky so we can avoid whatever it is in the future. In this case, we
should be able test this like we test clang code co
jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.
There are a whole bunch of other tests that test completion in this file that
use the exact same mechanism but don't seem to be flakey. Why is this one test
flakey?
If for instan
davide added a comment.
In https://reviews.llvm.org/D42656#991065, @jingham wrote:
> There are a whole bunch of other tests that test completion in this file that
> use the exact same mechanism but don't seem to be flakey. Why is this one
> test flakey?
>
> If for instance it's because "Fo" en
davide added a comment.
In https://reviews.llvm.org/D42656#991065, @jingham wrote:
> There are a whole bunch of other tests that test completion in this file that
> use the exact same mechanism but don't seem to be flakey. Why is this one
> test flakey?
>
> If for instance it's because "Fo" en
owenpshaw added a comment.
Hi Greg, I got distracted from this one for a bit. Maybe I missed it, but do
you have any thoughts on my previous comment/question about the batch API vs
other options?
Thanks,
Owen
https://reviews.llvm.org/D42145
___
davide added a comment.
In https://reviews.llvm.org/D42656#991065, @jingham wrote:
> There are a whole bunch of other tests that test completion in this file that
> use the exact same mechanism but don't seem to be flakey. Why is this one
> test flakey?
So, I take a look at this to reply to
davide added a comment.
In https://reviews.llvm.org/D42656#991239, @davide wrote:
> In https://reviews.llvm.org/D42656#991065, @jingham wrote:
>
> > There are a whole bunch of other tests that test completion in this file
> > that use the exact same mechanism but don't seem to be flakey. Why is
jingham added a comment.
So that sounds like a pexpect problem. We have seen that pexpect based tests
tend to be flakey, and particular will time out on loaded systems as you are
seeing. But I really don't think there are very many cases where we need to
use pexpect.
For instance, all the co
zturner added a comment.
If we just need to test completion, write a lit-style test that uses lldb-test
that looks like this:
RUN: lldb-test complete --target=%T/foo --complete_str=MyPrefix | FileCheck %s
CHECK: Foo::Bar
CHECK: Foo::Baz
etc
Simple and not flaky
https://reviews.llvm
jingham added a comment.
There are SB API's that call into the completion mechanism, so you could also
just change the TestCompletion.complete_from_to test method to call the SB
completion call. Given how the test is written, it looks like all you would
have to do is reimplement that method, a
zturner added a comment.
Spinning up a process just to test that auto-completion works though seems a
little bit unnecessary, and introduces the possibility that flakiness and bugs
in the process spawn mechanism (if any exist) will manifest in the test
failure. It would be nice, if and when th
Author: davide
Date: Mon Jan 29 15:24:50 2018
New Revision: 323707
URL: http://llvm.org/viewvc/llvm-project?rev=323707&view=rev
Log:
[test-suite] UNXfail several tests that now pass locally.
Another step towards enabling unexpected successes as failures
by default.
Modified:
lldb/trunk/pack
davide added a comment.
In https://reviews.llvm.org/D42656#991284, @zturner wrote:
> If we just need to test completion, write a lit-style test that uses
> lldb-test that looks like this:
>
> RUN: lldb-test complete --target=%T/foo --complete_str=MyPrefix | FileCheck
> %s
>
> CHECK: Foo::
clayborg added a comment.
There would be no spinning an instance, it would be call the API in python. No
extra process, done in process.
https://reviews.llvm.org/D42656
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org
clayborg added a comment.
In https://reviews.llvm.org/D42145#979629, @owenpshaw wrote:
> I'm not envisioning that anything else needs to change to use begin/end or
> care it's there. I guess the way I look at it, having
> ObjectFile::LoadInMemory do begin/end is basically the same as what you'
jingham added a comment.
Yes. We do need to have symbols to do symbol completion, which does require a
binary, but you don't need to run it. Most of the other tests in there (e.g.
simple command completion) should be able to work without even a binary. It
seems weird to add a potentially fal
dotest is also a potentially fallible layer on top of the SB Api call, but
one that involves *more* behind-the-scenes code between the test and code
being tested.
An lldb-test test would consist, in its entirety, of about 10 lines of
text. I don’t see how it’s possible to beat that from a simplici
jingham added a comment.
lldb testcases are know not to be flakey if they don't use pexpect, which these
wouldn't. The setup machinery for running a dotest based test is pretty well
tested at this point.
And the lldb-test test would not just magically come into being by writing the
lit-form t
We’ve had many instances of flakiness in non pexpect tests (on all
platforms). There’s no obvious pattern to when a test will be flaky.
Whether those are due to dotest or liblldb is an open question, but one
good way of answering those types of questions is to replace one source of
unknown-flakines
Also, I can think of at least 3 different companies/people who are
investing in LLDB for their downstream needs (who haven't publicly
announced this, so this isn't widely known), which involves bringing LLDB
up on currently unsupported platforms. It's easy to lose sight of what
that entails when y
So far, all the "flakey" tests I've analyzed - of which there have been not a
few over the years - have either been:
1) Why was pexpect so hard to get right when expect has been rock solid for
decades...
2) Tests whose setup conditions are hard to get right, or hard to have happen
on whatever m
I guess I don't see how having a test dive into lldb-test and do a bunch of
work opaque work that I can't really annotate makes for an easier debugging
scenario than a test were I can trivially insert code to query the state of the
test as it goes along. In the current testsuite, the progress o
On Mon, Jan 29, 2018 at 6:11 PM Jim Ingham wrote:
>
> The wider LLVM community tests a very different kind of tool than lldb,
> which leaves me less moved by the argumentum ad verecundiam than I might
> otherwise be.
>
But it's not a different kind of test than this particular test, which is
why
That doesn't seem to me a strong enough argument to me to justify devising a
parallel mechanism to the one we have to use for our more complex tests when it
also happens to serve this purpose perfectly well. Every time we make folks
learn to diagnose a different mode of failure we are putting a
owenpshaw added a comment.
Thanks. What I'm struggling to reconcile are your statements that users should
not have to know how things must happen, but then that we should make
ObjectFile::Load smart so it doesn't result in an unnecessary amount of
reads/writes. If writing to flash memory effe
Author: vedantk
Date: Mon Jan 29 19:36:00 2018
New Revision: 323723
URL: http://llvm.org/viewvc/llvm-project?rev=323723&view=rev
Log:
dotest: Apply --skip-categories to debug info categories
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
Modified: lldb/trunk/packages/Python/
alexshap updated this revision to Diff 131920.
alexshap added a comment.
Update, rerun the tests.
Repository:
rL LLVM
https://reviews.llvm.org/D42563
Files:
packages/Python/lldbsuite/test/linux/mix-dwo-and-regular-objects/Makefile
packages/Python/lldbsuite/test/linux/mix-dwo-and-regular
alexshap updated this revision to Diff 131921.
alexshap added a comment.
fix typo
Repository:
rL LLVM
https://reviews.llvm.org/D42563
Files:
packages/Python/lldbsuite/test/linux/mix-dwo-and-regular-objects/Makefile
packages/Python/lldbsuite/test/linux/mix-dwo-and-regular-objects/TestMix
alexshap updated this revision to Diff 131922.
alexshap added a comment.
one more update
Repository:
rL LLVM
https://reviews.llvm.org/D42563
Files:
packages/Python/lldbsuite/test/linux/mix-dwo-and-regular-objects/Makefile
packages/Python/lldbsuite/test/linux/mix-dwo-and-regular-objects/
alexshap updated this revision to Diff 131924.
alexshap added a comment.
fix comment
https://reviews.llvm.org/D42563
Files:
packages/Python/lldbsuite/test/linux/mix-dwo-and-regular-objects/Makefile
packages/Python/lldbsuite/test/linux/mix-dwo-and-regular-objects/TestMixedDwarfBinary.py
p
52 matches
Mail list logo
