[Lldb-commits] [lldb] r287320 - Revert "Remove an out param from ValueObject::GetValueForExpressionPath."

Author: zturner Date: Fri Nov 18 00:34:45 2016 New Revision: 287320 URL: http://llvm.org/viewvc/llvm-project?rev=287320&view=rev Log: Revert "Remove an out param from ValueObject::GetValueForExpressionPath." This reverts commit r287315, as it introduces a bug that breaks many things. Modified:

[Lldb-commits] [lldb] r287315 - Remove an out param from ValueObject::GetValueForExpressionPath.

Author: zturner Date: Thu Nov 17 23:45:41 2016 New Revision: 287315 URL: http://llvm.org/viewvc/llvm-project?rev=287315&view=rev Log: Remove an out param from ValueObject::GetValueForExpressionPath. This argument was only used in one place in the codebase, and it was in a non-critical log stateme

[Lldb-commits] [lldb] r287308 - Delete more dead code in ValueObject.

Author: zturner Date: Thu Nov 17 22:30:47 2016 New Revision: 287308 URL: http://llvm.org/viewvc/llvm-project?rev=287308&view=rev Log: Delete more dead code in ValueObject. Apparently these two enormous functions were dead. Which is good, since one was largely a copy of another function with only

[Lldb-commits] [lldb] r287307 - Remove some dead code in ValueObject.

Author: zturner Date: Thu Nov 17 21:51:19 2016 New Revision: 287307 URL: http://llvm.org/viewvc/llvm-project?rev=287307&view=rev Log: Remove some dead code in ValueObject. Originally I converted this entire function and all dependents to use StringRef, but there were some test failures that were

[Lldb-commits] Buildbot numbers for the week of 11/06/2016 - 11/12/2016

Hello everyone, Below are some buildbot numbers for the last week of 11/06/2016 - 11/12/2016. Please see the same data in attached csv files: The longest time each builder was red during the last week; "Status change ratio" by active builder (percent of builds that changed the builder status fro

[Lldb-commits] Buildbot numbers for the week of 10/30/2016 - 11/05/2016

Hello everyone, Below are some buildbot numbers for the week of 10/30/2016 - 11/05/2016. Please see the same data in attached csv files: The longest time each builder was red during the last week; "Status change ratio" by active builder (percent of builds that changed the builder status from gre

[Lldb-commits] [lldb] r287282 - Resubmit "Change RegisterValue getters / setters to use StringRef."

Author: zturner Date: Thu Nov 17 17:47:31 2016 New Revision: 287282 URL: http://llvm.org/viewvc/llvm-project?rev=287282&view=rev Log: Resubmit "Change RegisterValue getters / setters to use StringRef." This resubmits r287279 with a fix for the original issue, which was a trivial typo. Modified:

[Lldb-commits] [lldb] r287281 - Revert "Change RegisterValue getters / setters to use StringRef."

Author: zturner Date: Thu Nov 17 17:32:26 2016 New Revision: 287281 URL: http://llvm.org/viewvc/llvm-project?rev=287281&view=rev Log: Revert "Change RegisterValue getters / setters to use StringRef." This reverts commit r287279, which breaks some register tests on Linux. Modified: lldb/trunk

[Lldb-commits] [lldb] r287279 - Change RegisterValue getters / setters to use StringRef.

Author: zturner Date: Thu Nov 17 17:05:28 2016 New Revision: 287279 URL: http://llvm.org/viewvc/llvm-project?rev=287279&view=rev Log: Change RegisterValue getters / setters to use StringRef. In the process, found some functions that were duplicates of existing StringRef member functions. So dele

[Lldb-commits] [lldb] r287274 - Fix step-over when SymbolContext.function is missing and symbol is present.

Author: sammccall Date: Thu Nov 17 16:29:31 2016 New Revision: 287274 URL: http://llvm.org/viewvc/llvm-project?rev=287274&view=rev Log: Fix step-over when SymbolContext.function is missing and symbol is present. Summary: Fix step-over when SymbolContext.function is missing and symbol is present.

[Lldb-commits] [lldb] r287266 - Make GetRegisterByName() take a StringRef.

Author: zturner Date: Thu Nov 17 15:54:37 2016 New Revision: 287266 URL: http://llvm.org/viewvc/llvm-project?rev=287266&view=rev Log: Make GetRegisterByName() take a StringRef. This one is fairly trivial and only really involves changing function signatures and a few simple call-sites. Modified:

[Lldb-commits] [PATCH] D26804: Fix step-over when SymbolContext.function is missing and symbol is present.

jingham added a comment. Excellent, thanks for catching that. https://reviews.llvm.org/D26804 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D26804: Fix step-over when SymbolContext.function is missing and symbol is present.

> On Nov 17, 2016, at 1:45 PM, Sam McCall wrote: > > On Thu, Nov 17, 2016 at 10:29 PM, Jim Ingham > wrote: > Ah, good catch. That is not right. If there’s inlined function information, > you want to make sure you haven’t gone from one inlined function to another.

Re: [Lldb-commits] [PATCH] D26804: Fix step-over when SymbolContext.function is missing and symbol is present.

Ah, good catch. That is not right. If there’s inlined function information, you want to make sure you haven’t gone from one inlined function to another. But the symbol is always going to be the same in this case. Actually, the old code is a overly restrictive by comparing the blocks directly

[Lldb-commits] [lldb] r287259 - Convert Platform, Process, and Connection functions to StringRef.

Author: zturner Date: Thu Nov 17 15:15:14 2016 New Revision: 287259 URL: http://llvm.org/viewvc/llvm-project?rev=287259&view=rev Log: Convert Platform, Process, and Connection functions to StringRef. All tests pass on Linux and Windows. Modified: lldb/trunk/include/lldb/Core/Connection.h

[Lldb-commits] [PATCH] D26804: Fix step-over when SymbolContext.function is missing and symbol is present.

jingham accepted this revision. jingham added a comment. This revision is now accepted and ready to land. That way of doing it is fine too. https://reviews.llvm.org/D26804 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.o

Re: [Lldb-commits] [PATCH] D26804: Fix step-over when SymbolContext.function is missing and symbol is present.

Yes, comp unit equal, no function and symbol equal should be treated as equivalent. However, your check would call two SymbolContexts equivalent that had different CompUnits but the same symbol. I can’t see how that would happen in practice, but if it did something odd has gone on, and we prob

Re: [Lldb-commits] [lldb] r287242 - Rewrite all Property related functions in terms of StringRef.

I bet we don’t have enough test coverage in this area to ensure that these changes didn’t break things. Did you check how much test coverage there was? If it isn’t good, which is my guess for properties, then it is good hygiene to add more tests that pass in the old way before embarking on thi

[Lldb-commits] [lldb] r287242 - Rewrite all Property related functions in terms of StringRef.

Author: zturner Date: Thu Nov 17 12:08:12 2016 New Revision: 287242 URL: http://llvm.org/viewvc/llvm-project?rev=287242&view=rev Log: Rewrite all Property related functions in terms of StringRef. This was a bit tricky, especially for things like OptionValueArray and OptionValueDictionary since th

[Lldb-commits] [PATCH] D26676: Patch for lldb bug 26322 “core load hangs”

clayborg added a comment. Checking core files into the repository will grow all git based repositories over time as every version of every core file will be included in the git clone. We have avoided checking in core files or any other larger files for this very reason. Not sure what the right

[Lldb-commits] [PATCH] D26676: Patch for lldb bug 26322 “core load hangs”

hhellyer added a comment. I'd assumed that gcore would ignore the coredump_filter setting but it turns out it doesn't so I should be able to use that. lldb seems happy enough opening the core files produced with a filter of 0 so it's probably the simplest solution. I don't think lldb has a cor

[Lldb-commits] [PATCH] D26676: Patch for lldb bug 26322 “core load hangs”

labath added a comment. In https://reviews.llvm.org/D26676#598559, @hhellyer wrote: > I haven't solved that yet! ;-) > > I'm currently ending up with cores of ~500kb which is probably too big. I'm > seeing what I can do to bring them down but it might be that I can't shrink > them that much. I

[Lldb-commits] [PATCH] D26676: Patch for lldb bug 26322 “core load hangs”

hhellyer added a comment. I haven't solved that yet! ;-) I'm currently ending up with cores of ~500kb which is probably too big. I'm seeing what I can do to bring them down but it might be that I can't shrink them that much. I'm attempting to write two tests, one for multiple threads and one

[Lldb-commits] [PATCH] D26676: Patch for lldb bug 26322 “core load hangs”

labath added a comment. I can't say we're being very consistent in enforcing it, but general llvm policy is for tests to go together with the changes. I am curious, how do you go about creating these core files? The core files I created were very tiny as I did not require any syscalls, so I co

[Lldb-commits] [PATCH] D26676: Patch for lldb bug 26322 “core load hangs”

hhellyer added a comment. This is marked ready to land and I can land it now but I'm still working on the testcases. I can either: - Land the code changes and do the tests under another patch. - Hold off on delivering this until I've finished the tests. I'm not sure which is the preferred optio