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

davide added a comment. In https://reviews.llvm.org/D42563#988700, @alexshap wrote: > @davide - the test case is in the description but i can try to add it to the > test suite. yes, please. Repository: rL LLVM https://reviews.llvm.org/D42563

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

alexshap added a comment. @davide - the test case is in the description but i can try to add it to the test suite. Repository: rL LLVM https://reviews.llvm.org/D42563 ___ lldb-commits mailing list lldb-commits@lists.llvm.org

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

davide requested changes to this revision. davide added a comment. This revision now requires changes to proceed. Testcase? Repository: rL LLVM https://reviews.llvm.org/D42563 ___ lldb-commits mailing list lldb-commits@lists.llvm.org

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

alexshap created this revision. alexshap added reviewers: tberghammer, labath, clayborg. Herald added subscribers: llvm-commits, JDevlieghere, aprantl. A small test where the issue is easy to reproduce: a.cpp: int f() { return 1; } b.cpp: extern int f(); void g() { int y =

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

jingham requested changes to this revision. jingham added a comment. This revision now requires changes to proceed. This looks good to me. I think it would be cleaner if there were a getSourceFileSpec equivalent to getBuildArtifact. I had a few inline trivial questions. Also, before you

Re: [Lldb-commits] [lldb] r323450 - Use test-specific module caches to avoid stale header conflicts

Cheer on! On Thu, Jan 25, 2018 at 2:04 PM, Vedant Kumar wrote: > Green: http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/4760/console > > On Jan 25, 2018, at 1:22 PM, Vedant Kumar wrote: > > Done, r323467 > > On Jan 25, 2018, at 1:20 PM, Davide Italiano

Re: [Lldb-commits] [lldb] r323450 - Use test-specific module caches to avoid stale header conflicts

Green: http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/4760/console > On Jan 25, 2018, at 1:22 PM, Vedant Kumar wrote: > > Done, r323467 > >> On Jan 25, 2018, at 1:20 PM, Davide Italiano

Re: [Lldb-commits] [lldb] r323450 - Use test-specific module caches to avoid stale header conflicts

Done, r323467 > On Jan 25, 2018, at 1:20 PM, Davide Italiano wrote: > > yes, sure, I think that's the right thing to do. > > -- > Davide > > On Thu, Jan 25, 2018 at 1:16 PM, Vedant Kumar wrote: >> We *could* x-fail this test on older OS's, but ISTM that

[Lldb-commits] [lldb] r323467 - [test] Fix a test that never compiled under -fmodules

Author: vedantk Date: Thu Jan 25 13:20:29 2018 New Revision: 323467 URL: http://llvm.org/viewvc/llvm-project?rev=323467=rev Log: [test] Fix a test that never compiled under -fmodules This test #include's stdio.h, which, on at least two bots results in a module import of MacTypes.h (due to weird

Re: [Lldb-commits] [lldb] r323450 - Use test-specific module caches to avoid stale header conflicts

yes, sure, I think that's the right thing to do. -- Davide On Thu, Jan 25, 2018 at 1:16 PM, Vedant Kumar wrote: > We *could* x-fail this test on older OS's, but ISTM that we don't need this > test to printf at all, so let's just remove the #include? > > vedant > > On Jan 25,

Re: [Lldb-commits] [lldb] r323450 - Use test-specific module caches to avoid stale header conflicts

I see, thanks. It looks like this is illformed C++, I'll take a look. Thanks, -- Davide On Thu, Jan 25, 2018 at 1:14 PM, Vedant Kumar wrote: > The test passes locally, but the cmake job is failing in the exact same way > as the Xcode one. Based on the error, it looks like the

Re: [Lldb-commits] [lldb] r323450 - Use test-specific module caches to avoid stale header conflicts

We *could* x-fail this test on older OS's, but ISTM that we don't need this test to printf at all, so let's just remove the #include? vedant > On Jan 25, 2018, at 1:14 PM, Vedant Kumar wrote: > > The test passes locally, but the cmake job is failing in the exact same way > as

Re: [Lldb-commits] [lldb] r323450 - Use test-specific module caches to avoid stale header conflicts

The test passes locally, but the cmake job is failing in the exact same way as the Xcode one. Based on the error, it looks like the compiler invocation has failed. .. and, aha!, here is the failed invocation: green-dragon-23:non-overlapping-index-variable-i buildslave$ make MAKE_DSYM=NO

Re: [Lldb-commits] [lldb] r323450 - Use test-specific module caches to avoid stale header conflicts

Taking a look. It may be another instance of a test not actually running with -fmodules in the -gmodules configuration. vedant > On Jan 25, 2018, at 12:40 PM, Davide Italiano wrote: > > The bot started failing recently, and this commit seems the most likely > culprit.

Re: [Lldb-commits] [lldb] r323450 - Use test-specific module caches to avoid stale header conflicts

The bot started failing recently, and this commit seems the most likely culprit. http://lab.llvm.org:8080/green/view/LLDB/job/lldb-xcode/4513/ Can you please take a look, Vedant? Thanks, -- Davide On Thu, Jan 25, 2018 at 10:01 AM, Vedant Kumar via lldb-commits

[Lldb-commits] [PATCH] D42277: Use test-specific module caches to avoid stale header conflicts

This revision was automatically updated to reflect the committed changes. Closed by commit rL323450: Use test-specific module caches to avoid stale header conflicts (authored by vedantk, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit:

[Lldb-commits] [lldb] r323450 - Use test-specific module caches to avoid stale header conflicts

Author: vedantk Date: Thu Jan 25 10:01:27 2018 New Revision: 323450 URL: http://llvm.org/viewvc/llvm-project?rev=323450=rev Log: Use test-specific module caches to avoid stale header conflicts Stale global module caches cause problems for the bots. The modules become invalid when clang headers

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

owenpshaw added a comment. Thanks for the help! Someone with commit access will need to land it. https://reviews.llvm.org/D42195 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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

krytarowski added a comment. Looks fine. https://reviews.llvm.org/D42488 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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

clayborg accepted this revision. clayborg added a comment. Thanks for iterating on this. This will be great. https://reviews.llvm.org/D42195 ___ lldb-commits mailing list lldb-commits@lists.llvm.org

[Lldb-commits] [PATCH] D31451: New C++ function name parsing logic

clayborg added a comment. In https://reviews.llvm.org/D31451#987537, @labath wrote: > This code is processing demangled names. Since you say (I could not get my > demangler to process it either) the symbol demangles to a multi-megabyte > name, we can probably make the cutoff even longer then

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

labath accepted this revision. labath added a comment. This revision is now accepted and ready to land. This is great. Thank you for doing this. I think we're ready to wrap this up. https://reviews.llvm.org/D42195 ___ lldb-commits mailing list

[Lldb-commits] [PATCH] D31451: New C++ function name parsing logic

labath added a comment. This code is processing demangled names. Since you say (I could not get my demangler to process it either) the symbol demangles to a multi-megabyte name, we can probably make the cutoff even longer then 1000 bytes. OTOH, if we abort demangling of such names in the first

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

labath updated this revision to Diff 131401. labath added a comment. This revision is now accepted and ready to land. Ok, so the issue was a subsequent MergeFrom(HostArchitecture) call which was overwriting the invalid ArchSpec I was returning here. I think this was present there to fill in the