Re: [Lldb-commits] [PATCH] D21751: Implement GetMemoryRegions() for Linux and Mac OSX core files.
hhellyer added a comment. Since there’s a list of memory regions already created in the Process implementations for the core fles I thought it made sense just to use that directly, at least when reading from a core file. It meant there was no requirement to change those GetMemoryRegionInfo implementations if they didn’t behave quite the same. That said it is roughly what I planned to do for the live connections as the behaviour of the qMemoryRegionInfo query is more tightly specified and moving to that model would just push that implementation one layer higher. I will push a revision which follows the approach you suggest, if we find that throws up it’s own problems then I can always revert. As I mentioned the remote connections should (hopefully) all work with that pattern so GetMemoryRegions implemented in fewer commits with that approach. Is PAGEZERO actually included in Mac core dumps? I can see it as load command 0 when I run otool against an executable but when I look at a core dump from the same executable the first load command looks like load command 1 in the executable. There doesn’t seem to be a load command in the core for address 0. I might just be missing an flag on otool though. http://reviews.llvm.org/D21751 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D21751: Implement GetMemoryRegions() for Linux and Mac OSX core files.
clayborg added a comment. In http://reviews.llvm.org/D21751#468738, @hhellyer wrote: > Since there’s a list of memory regions already created in the Process > implementations for the core fles I thought it made sense just to use that > directly, at least when reading from a core file. It meant there was no > requirement to change those GetMemoryRegionInfo implementations if they > didn’t behave quite the same. That said it is roughly what I planned to do > for the live connections as the behaviour of the qMemoryRegionInfo query is > more tightly specified and moving to that model would just push that > implementation one layer higher. We should document the Process::GetMemoryRegionInfo() and what we expect of it so that all plug-ins implement it correctly. > I will push a revision which follows the approach you suggest, if we find > that throws up it’s own problems then I can always revert. As I mentioned the > remote connections should (hopefully) all work with that pattern so > GetMemoryRegions implemented in fewer commits with that approach. Indeed. Since we already expect a behavior from Process::GetMemoryRegionInfo(), I would say lets enforce these requirements by making Process::GetMemoryRegions() just use that API as required. The only time we should see an error from Process::GetMemoryRegionInfo() is when it isn't implemented. > Is PAGEZERO actually included in Mac core dumps? I can see it as load command > 0 when I run otool against an executable but when I look at a core dump from > the same executable the first load command looks like load command 1 in the > executable. There doesn’t seem to be a load command in the core for address > 0. I might just be missing an flag on otool though. It might not be, but that brings up another thing I was thinking of is that we could start supplementing the Process::GetMemoryRegionInfo() info by also looking in any sections that were found in core file memory that might not be fully described by the core file itself. There is no requirements that if two sections are adjacent in a core file that they show up as different mapped regions, so you might find a mapped section of memory from 0x1000-0x8000 that is actually 0x1000-0x4000 for ".data" and 0x4000-0x8000 that is ".bss". The memory region was mapped read+write, but would it be nice to know about these different regions separately? We don't need to do this now, but this is one place where we could figure out that 0x0-0x1 is __PAGEZERO even though it isn't mapped into the current mach-o file's memory regions. Also there are different makers of core files: lldb, the kernel, possibly others. They don't always follow the same rules when making mach-o core files. So it is nice to be flexible. http://reviews.llvm.org/D21751 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r274032 - Process::StopForDetachOrDestroy should actually return an error if it can't stop the
Author: jingham
Date: Tue Jun 28 11:35:58 2016
New Revision: 274032
URL: http://llvm.org/viewvc/llvm-project?rev=274032&view=rev
Log:
Process::StopForDetachOrDestroy should actually return an error if it can't
stop the
process.
Modified:
lldb/trunk/source/Target/Process.cpp
Modified: lldb/trunk/source/Target/Process.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/Process.cpp?rev=274032&r1=274031&r2=274032&view=diff
==
--- lldb/trunk/source/Target/Process.cpp (original)
+++ lldb/trunk/source/Target/Process.cpp Tue Jun 28 11:35:58 2016
@@ -3683,7 +3683,7 @@ Process::StopForDestroyOrDetach(lldb::Ev
StateType private_state = m_private_state.GetValue();
if (private_state != eStateStopped)
{
-return error;
+return Error("Attempt to stop the target in order to detach
timed out. State = %s", StateAsCString(GetState()));
}
}
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r274037 - 64-bit LEB values are not always correctly decoded due to a casting issue, now they are.
Author: gclayton
Date: Tue Jun 28 12:14:18 2016
New Revision: 274037
URL: http://llvm.org/viewvc/llvm-project?rev=274037&view=rev
Log:
64-bit LEB values are not always correctly decoded due to a casting issue, now
they are.
Modified:
lldb/trunk/source/Core/DataExtractor.cpp
lldb/trunk/source/Symbol/ArmUnwindInfo.cpp
lldb/trunk/tools/debugserver/source/DNBDataRef.cpp
Modified: lldb/trunk/source/Core/DataExtractor.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/DataExtractor.cpp?rev=274037&r1=274036&r2=274037&view=diff
==
--- lldb/trunk/source/Core/DataExtractor.cpp (original)
+++ lldb/trunk/source/Core/DataExtractor.cpp Tue Jun 28 12:14:18 2016
@@ -1237,7 +1237,7 @@ DataExtractor::GetULEB128 (offset_t *off
while (src < end)
{
uint8_t byte = *src++;
-result |= (byte & 0x7f) << shift;
+result |= (uint64_t)(byte & 0x7f) << shift;
if ((byte & 0x80) == 0)
break;
shift += 7;
@@ -1280,7 +1280,7 @@ DataExtractor::GetSLEB128 (offset_t *off
{
bytecount++;
byte = *src++;
-result |= (byte & 0x7f) << shift;
+result |= (int64_t)(byte & 0x7f) << shift;
shift += 7;
if ((byte & 0x80) == 0)
break;
Modified: lldb/trunk/source/Symbol/ArmUnwindInfo.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/ArmUnwindInfo.cpp?rev=274037&r1=274036&r2=274037&view=diff
==
--- lldb/trunk/source/Symbol/ArmUnwindInfo.cpp (original)
+++ lldb/trunk/source/Symbol/ArmUnwindInfo.cpp Tue Jun 28 12:14:18 2016
@@ -103,7 +103,7 @@ ArmUnwindInfo::GetULEB128(const uint32_t
while (offset < max_offset)
{
uint8_t byte = GetByteAtOffset(data, offset++);
-result |= (byte & 0x7f) << shift;
+result |= (uint64_t)(byte & 0x7f) << shift;
if ((byte & 0x80) == 0)
break;
shift += 7;
Modified: lldb/trunk/tools/debugserver/source/DNBDataRef.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/debugserver/source/DNBDataRef.cpp?rev=274037&r1=274036&r2=274037&view=diff
==
--- lldb/trunk/tools/debugserver/source/DNBDataRef.cpp (original)
+++ lldb/trunk/tools/debugserver/source/DNBDataRef.cpp Tue Jun 28 12:14:18 2016
@@ -250,7 +250,7 @@ DNBDataRef::Get_ULEB128 (offset_t *offse
{
bytecount++;
byte = *src++;
-result |= (byte & 0x7f) << shift;
+result |= (uint64_t)(byte & 0x7f) << shift;
shift += 7;
if ((byte & 0x80) == 0)
break;
@@ -283,7 +283,7 @@ DNBDataRef::Get_SLEB128 (offset_t *offse
{
bytecount++;
byte = *src++;
-result |= (byte & 0x7f) << shift;
+result |= (int64_t)(byte & 0x7f) << shift;
shift += 7;
if ((byte & 0x80) == 0)
break;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D21328: [lldb] Fixed incorrect endianness when evaluating certain expressions
cameron314 added a comment. @spyffe, do you have a minute to look this over? http://reviews.llvm.org/D21328 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] Buildbot numbers for the last week of 6/19/2016 - 6/25/2016
Hello everyone, Below are some buildbot numbers for the last week of 6/19/2016 - 6/25/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 greed to red or from red to green); Count of commits by project; Number of completed builds, failed builds and average build time for successful builds per active builder; Average waiting time for a revision to get build result per active builder (response time); Thanks Galina The longest time each builder was red during the last week: buildername | was_red --+--- lldb-x86-windows-msvc2015| 132:47:15 sanitizer-x86_64-linux-fast | 58:07:21 sanitizer-x86_64-linux | 48:59:06 perf-x86_64-penryn-O3| 41:37:20 clang-cmake-thumbv7-a15-full-sh | 34:34:23 clang-cmake-armv7-a15-selfhost | 34:18:12 clang-cmake-mipsel | 30:27:12 clang-x86-win2008-selfhost | 25:04:16 clang-ppc64be-linux-lnt | 24:21:09 sanitizer-x86_64-linux-bootstrap | 24:01:14 clang-ppc64be-linux-multistage | 23:07:28 clang-cmake-armv7-a15-selfhost-neon | 22:57:51 clang-ppc64le-linux-lnt | 19:37:05 clang-ppc64le-linux | 18:39:01 clang-cmake-mips | 18:27:47 clang-s390x-linux| 18:23:18 clang-ppc64be-linux | 18:20:46 clang-ppc64le-linux-multistage | 18:06:13 clang-native-aarch64-full| 15:48:44 lldb-x86_64-ubuntu-14.04-cmake | 14:34:45 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast | 12:15:24 lldb-windows7-android| 11:00:17 clang-atom-d525-fedora-rel | 08:43:11 clang-x86_64-linux-selfhost-modules | 08:31:25 perf-x86_64-penryn-O3-polly | 08:03:30 llvm-clang-lld-x86_64-debian-fast| 06:27:29 clang-x64-ninja-win7 | 06:22:40 lldb-x86_64-ubuntu-14.04-android | 05:53:09 llvm-mips-linux | 05:38:44 lld-x86_64-win7 | 05:21:12 clang-native-arm-lnt | 04:15:53 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast | 04:00:56 clang-cmake-armv7-a15-full | 03:49:33 sanitizer-ppc64le-linux | 03:32:36 clang-cmake-aarch64-full | 03:17:37 clang-x86_64-debian-fast | 02:55:23 clang-cmake-armv7-a15| 02:38:03 clang-cmake-thumbv7-a15 | 02:36:39 clang-cmake-aarch64-quick| 02:30:09 clang-cmake-aarch64-42vma| 02:12:53 lldb-x86_64-ubuntu-14.04-buildserver | 02:02:40 libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11 | 01:55:09 clang-3stage-ubuntu | 01:48:54 clang-cuda-build | 01:43:56 sanitizer-ppc64be-linux | 01:43:19 polly-amd64-linux| 01:41:23 clang-hexagon-elf| 01:38:38 lldb-x86_64-darwin-13.4 | 01:34:23 libcxx-libcxxabi-x86_64-linux-ubuntu-asan| 01:27:16 lld-x86_64-darwin13 | 01:26:31 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14 | 01:25:36 lld-x86_64-freebsd | 01:24:39 sanitizer-windows| 01:21:29 lldb-amd64-ninja-netbsd7 | 01:16:52 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx1z | 01:16:27 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11 | 01:15:06 perf-x86_64-penryn-O3-polly-unprofitable | 01:08:08 sanitizer-x86_64-linux-fuzzer| 01:00:19 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03 | 00:49:27 perf-x86_64-penryn-O3-polly-parallel-fast| 00:38:09 sanitizer-x86_64-linux-autoconf | 00:36:04 clang-x86_64-linux-abi-test | 00:23:03 llvm-hexagon-elf | 00:11:20 (63 rows) "Status change ratio" by active builder (percent of builds that changed the builder status from greed to red or from red to green): buildername| builds | changes | status change ratio ++-+- perf-x86_64-penryn-O3-polly
[Lldb-commits] LLVM buildmaster will be restarted tonight
Hello everyone, LLVM buildmaster will be updated and restarted after 8 PM Pacific time today. Thanks Galina ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
