[Lldb-commits] [PATCH] D42563: [lldb] attempt to fix DIERef::GetUID

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

[Lldb-commits] [PATCH] D42563: [lldb] attempt to fix DIERef::GetUID

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

[Lldb-commits] [PATCH] D42563: [lldb] attempt to fix DIERef::GetUID

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

[Lldb-commits] [lldb] r323723 - dotest: Apply --skip-categories to debug info categories

Author: vedantk Date: Mon Jan 29 19:36:00 2018 New Revision: 323723 URL: http://llvm.org/viewvc/llvm-project?rev=323723=rev Log: dotest: Apply --skip-categories to debug info categories Modified: lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py Modified:

[Lldb-commits] [PATCH] D42145: [lldb] Use vFlash commands when writing to target's flash memory regions

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

Re: [Lldb-commits] [PATCH] D42656: [testsuite] Remove flakey test relying on `pexpect`

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

Re: [Lldb-commits] [PATCH] D42656: [testsuite] Remove flakey test relying on `pexpect`

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

Re: [Lldb-commits] [PATCH] D42656: [testsuite] Remove flakey test relying on `pexpect`

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

Re: [Lldb-commits] [PATCH] D42656: [testsuite] Remove flakey test relying on `pexpect`

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

Re: [Lldb-commits] [PATCH] D42656: [testsuite] Remove flakey test relying on `pexpect`

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

Re: [Lldb-commits] [PATCH] D42656: [testsuite] Remove flakey test relying on `pexpect`

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

[Lldb-commits] [PATCH] D42656: [testsuite] Remove flakey test relying on `pexpect`

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

Re: [Lldb-commits] [PATCH] D42656: [testsuite] Remove flakey test relying on `pexpect`

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

[Lldb-commits] [PATCH] D42656: [testsuite] Remove flakey test relying on `pexpect`

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

[Lldb-commits] [PATCH] D42145: [lldb] Use vFlash commands when writing to target's flash memory regions

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

[Lldb-commits] [PATCH] D42656: [testsuite] Remove flakey test relying on `pexpect`

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

[Lldb-commits] [PATCH] D42656: [testsuite] Remove flakey test relying on `pexpect`

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:

[Lldb-commits] [lldb] r323707 - [test-suite] UNXfail several tests that now pass locally.

Author: davide Date: Mon Jan 29 15:24:50 2018 New Revision: 323707 URL: http://llvm.org/viewvc/llvm-project?rev=323707=rev Log: [test-suite] UNXfail several tests that now pass locally. Another step towards enabling unexpected successes as failures by default. Modified:

[Lldb-commits] [PATCH] D42656: [testsuite] Remove flakey test relying on `pexpect`

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

[Lldb-commits] [PATCH] D42656: [testsuite] Remove flakey test relying on `pexpect`

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,

[Lldb-commits] [PATCH] D42656: [testsuite] Remove flakey test relying on `pexpect`

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

[Lldb-commits] [PATCH] D42656: [testsuite] Remove flakey test relying on `pexpect`

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

[Lldb-commits] [PATCH] D42656: [testsuite] Remove flakey test relying on `pexpect`

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

[Lldb-commits] [PATCH] D42656: [testsuite] Remove flakey test relying on `pexpect`

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

[Lldb-commits] [PATCH] D42145: [lldb] Use vFlash commands when writing to target's flash memory regions

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 ___

[Lldb-commits] [PATCH] D42656: [testsuite] Remove flakey test relying on `pexpect`

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"

[Lldb-commits] [PATCH] D42656: [testsuite] Remove flakey test relying on `pexpect`

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"

[Lldb-commits] [PATCH] D42656: [testsuite] Remove flakey test relying on `pexpect`

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

[Lldb-commits] [PATCH] D42656: [testsuite] Remove flakey test relying on `pexpect`

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

[Lldb-commits] [lldb] r323673 - [Host] Respect LLVM_LIBDIR_SUFFIX when looking for LLDB plugins on Linux

Author: mgorny Date: Mon Jan 29 10:25:06 2018 New Revision: 323673 URL: http://llvm.org/viewvc/llvm-project?rev=323673=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

[Lldb-commits] [PATCH] D42317: [Host] Respect LLVM_LIBDIR_SUFFIX when looking for LLDB plugins on Linux

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:

[Lldb-commits] [PATCH] D42281: Compile the LLDB tests out-of-tree

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

[Lldb-commits] [PATCH] D42317: [Host] Respect LLVM_LIBDIR_SUFFIX when looking for LLDB plugins on Linux

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

Re: [Lldb-commits] [lldb] r322339 - When parsing the target.xml register file, if no architecture has

> 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

Re: [Lldb-commits] [PATCH] D42386: Fix memory leak in TestClangASTContext.TestRecordHasFields

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

Re: [Lldb-commits] [PATCH] D42386: Fix memory leak in TestClangASTContext.TestRecordHasFields

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 >

[Lldb-commits] [PATCH] D42317: [Host] Respect LLVM_LIBDIR_SUFFIX when looking for LLDB plugins on Linux

mgorny added inline comments. Comment at: source/Host/linux/HostInfoLinux.cpp:208 bool HostInfoLinux::ComputeSystemPluginsDirectory(FileSpec _spec) { - FileSpec temp_file("/usr/lib/lldb/plugins", true); + FileSpec temp_file("/usr/lib" LLDB_LIBDIR_SUFFIX "/lldb/plugins",

[Lldb-commits] [PATCH] D42317: [Host] Respect LLVM_LIBDIR_SUFFIX when looking for LLDB plugins on Linux

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

[Lldb-commits] [PATCH] D42317: [Host] Respect LLVM_LIBDIR_SUFFIX when looking for LLDB plugins on Linux

clayborg added inline comments. Comment at: source/Host/linux/HostInfoLinux.cpp:208 bool HostInfoLinux::ComputeSystemPluginsDirectory(FileSpec _spec) { - FileSpec temp_file("/usr/lib/lldb/plugins", true); + FileSpec temp_file("/usr/lib" LLDB_LIBDIR_SUFFIX "/lldb/plugins",

[Lldb-commits] [PATCH] D42317: [Host] Respect LLVM_LIBDIR_SUFFIX when looking for LLDB plugins on Linux

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

[Lldb-commits] [PATCH] D42281: Compile the LLDB tests out-of-tree

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

[Lldb-commits] [PATCH] D42620: [lldb] Silence signed <-> unsigned integer comparison warning

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:

[Lldb-commits] [PATCH] D42620: [lldb] Silence signed <-> unsigned integer comparison warning

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

[Lldb-commits] [PATCH] D42563: [lldb] attempt to fix DIERef::GetUID

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

[Lldb-commits] [lldb] r323639 - Fix NetBsd build broken by r323637

Author: labath Date: Mon Jan 29 03:10:21 2018 New Revision: 323639 URL: http://llvm.org/viewvc/llvm-project?rev=323639=rev Log: Fix NetBsd build broken by r323637 Modified: lldb/trunk/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp Modified:

[Lldb-commits] [PATCH] D42488: Remove ObjectFile usage from HostLinux::GetProcessInfo

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:

[Lldb-commits] [lldb] r323637 - Remove ObjectFile usage from HostLinux::GetProcessInfo

Author: labath Date: Mon Jan 29 02:46:00 2018 New Revision: 323637 URL: http://llvm.org/viewvc/llvm-project?rev=323637=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 main

[Lldb-commits] [PATCH] D42195: [lldb] Generic base for testing gdb-remote behavior

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:

[Lldb-commits] [lldb] r323636 - [lldb] Generic base for testing gdb-remote behavior

Author: labath Date: Mon Jan 29 02:02:40 2018 New Revision: 323636 URL: http://llvm.org/viewvc/llvm-project?rev=323636=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-remote

[Lldb-commits] [PATCH] D42281: Compile the LLDB tests out-of-tree

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