[Lldb-commits] [lldb] r254294 - [RS] Support RenderScript struct allocations
Author: ewancrawford
Date: Mon Nov 30 04:29:49 2015
New Revision: 254294
URL: http://llvm.org/viewvc/llvm-project?rev=254294&view=rev
Log:
[RS] Support RenderScript struct allocations
This patch adds functionality for dumping allocations of struct elements. This
involves:
+ Jitting the runtime for details on all the struct fields.
+ Finding the name of the struct type by looking for a global variable of
the same type, which will have been reflected back to the java host code.
+ Using this struct type name to pass into expression evaluation for pretty
printing the data for the dump command.
Modified:
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.h
Modified:
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp?rev=254294&r1=254293&r2=254294&view=diff
==
---
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
(original)
+++
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
Mon Nov 30 04:29:49 2015
@@ -18,7 +18,9 @@
#include "lldb/Core/Error.h"
#include "lldb/Core/Log.h"
#include "lldb/Core/PluginManager.h"
+#include "lldb/Core/ValueObjectVariable.h"
#include "lldb/Core/RegularExpression.h"
+#include "lldb/DataFormatters/DumpValueObjectOptions.h"
#include "lldb/Host/StringConvert.h"
#include "lldb/Symbol/Symbol.h"
#include "lldb/Symbol/Type.h"
@@ -133,42 +135,61 @@ struct RenderScriptRuntime::ScriptDetail
empirical_type script;
};
+// This Element class represents the Element object in RS,
+// defining the type associated with an Allocation.
+struct RenderScriptRuntime::Element
+{
+// Taken from rsDefines.h
+enum DataKind
+{
+RS_KIND_USER,
+RS_KIND_PIXEL_L = 7,
+RS_KIND_PIXEL_A,
+RS_KIND_PIXEL_LA,
+RS_KIND_PIXEL_RGB,
+RS_KIND_PIXEL_RGBA,
+RS_KIND_PIXEL_DEPTH,
+RS_KIND_PIXEL_YUV,
+RS_KIND_INVALID = 100
+};
+
+// Taken from rsDefines.h
+enum DataType
+{
+RS_TYPE_NONE = 0,
+RS_TYPE_FLOAT_16,
+RS_TYPE_FLOAT_32,
+RS_TYPE_FLOAT_64,
+RS_TYPE_SIGNED_8,
+RS_TYPE_SIGNED_16,
+RS_TYPE_SIGNED_32,
+RS_TYPE_SIGNED_64,
+RS_TYPE_UNSIGNED_8,
+RS_TYPE_UNSIGNED_16,
+RS_TYPE_UNSIGNED_32,
+RS_TYPE_UNSIGNED_64,
+RS_TYPE_BOOLEAN
+};
+
+std::vector children; // Child Element
fields for structs
+empirical_type element_ptr;// Pointer to the RS
Element of the Type
+empirical_type type; // Type of each data
pointer stored by the allocation
+empirical_type type_kind; // Defines pixel type
if Allocation is created from an image
+empirical_type type_vec_size; // Vector size of
each data point, e.g '4' for uchar4
+empirical_type field_count;// Number of
Subelements
+empirical_type datum_size; // Size of a single
Element with padding
+empirical_type padding;// Number of padding
bytes
+empirical_type array_size; // Number of items in
array, only needed for strucrs
+ConstString type_name; // Name of type, only
needed for structs
+
+static const ConstString FallbackStructName; // Print this as the
type name of a struct Element
+ // If we can't
resolve the actual struct name
+};
+
// This AllocationDetails class collects data associated with a single
// allocation instance.
struct RenderScriptRuntime::AllocationDetails
{
- // Taken from rsDefines.h
- enum DataKind
- {
- RS_KIND_USER,
- RS_KIND_PIXEL_L = 7,
- RS_KIND_PIXEL_A,
- RS_KIND_PIXEL_LA,
- RS_KIND_PIXEL_RGB,
- RS_KIND_PIXEL_RGBA,
- RS_KIND_PIXEL_DEPTH,
- RS_KIND_PIXEL_YUV,
- RS_KIND_INVALID = 100
- };
-
- // Taken from rsDefines.h
- enum DataType
- {
- RS_TYPE_NONE = 0,
- RS_TYPE_FLOAT_16,
- RS_TYPE_FLOAT_32,
- RS_TYPE_FLOAT_64,
- RS_TYPE_SIGNED_8,
- RS_TYPE_SIGNED_16,
- RS_TYPE_SIGNED_32,
- RS_TYPE_SIGNED_64,
- RS_TYPE_UNSIGNED_8,
- RS_TYPE_UNSIGNED_16,
- RS_TYPE_UNSIGNED_32,
- RS_TYPE_UNSIGNED_64,
- RS_TYPE_BOOLEAN
-};
-
struct Dimension
{
uint32_t dim_1;
@@ -214,14 +235,11 @@ struct RenderScriptRuntime::AllocationDe
// for commands to reference it.
const uns
Re: [Lldb-commits] [PATCH] D15067: Design building out of sources
labath added subscribers: artagnon, Eugene.Zelenko, tfiala. labath added a comment. It seems to follow what clang does here, so I think it should be ok. However, I'm not actually using the standalone build... I've added some people who I think might be using it. Let's give them a bit of time to respond. If there are no objections, then I'll commit this.. Repository: rL LLVM http://reviews.llvm.org/D15067 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D15061: Correction in TestFrames.py test for arm targets in thumb mode
tberghammer accepted this revision. tberghammer added a comment. This revision is now accepted and ready to land. LGTM Note: We will have to enable the same functionality for some variant of mips also but I don't know the details so we should leave it for the mips guys. http://reviews.llvm.org/D15061 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D15042: PTRACE ABI to read FXSAVE area for 32-bit inferior
abhishek.aggarwal updated this revision to Diff 41382.
abhishek.aggarwal added a comment.
Removed assert if ptrace API fails
http://reviews.llvm.org/D15042
Files:
packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
Index: source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
===
--- source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
+++ source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
@@ -327,6 +327,9 @@
#ifndef NT_X86_XSTATE
#define NT_X86_XSTATE 0x202
#endif
+#ifndef NT_PRXFPREG
+#define NT_PRXFPREG 0x46e62b7f
+#endif
NativeRegisterContextLinux*
NativeRegisterContextLinux::CreateHostNativeRegisterContextLinux(const
ArchSpec& target_arch,
@@ -868,10 +871,24 @@
NativeRegisterContextLinux_x86_64::WriteFPR()
{
const FPRType fpr_type = GetFPRType ();
+const lldb_private::ArchSpec& target_arch =
GetRegisterInfoInterface().GetTargetArchitecture();
switch (fpr_type)
{
case FPRType::eFPRTypeFXSAVE:
-return NativeRegisterContextLinux::WriteFPR();
+// For 32-bit inferiors on x86_32/x86_64 architectures,
+// FXSAVE area can be written using PTRACE_SETREGSET ptrace api
+// For 64-bit inferiors on x86_64 architectures,
+// FXSAVE area can be written using PTRACE_SETFPREGS ptrace api
+switch (target_arch.GetMachine ())
+{
+case llvm::Triple::x86:
+return WriteRegisterSet(&m_iovec, sizeof(m_fpr.xstate.xsave),
NT_PRXFPREG);
+case llvm::Triple::x86_64:
+return NativeRegisterContextLinux::WriteFPR();
+default:
+assert(false && "Unhandled target architecture.");
+break;
+}
case FPRType::eFPRTypeXSAVE:
return WriteRegisterSet(&m_iovec, sizeof(m_fpr.xstate.xsave),
NT_X86_XSTATE);
default:
@@ -980,10 +997,24 @@
NativeRegisterContextLinux_x86_64::ReadFPR ()
{
const FPRType fpr_type = GetFPRType ();
+const lldb_private::ArchSpec& target_arch =
GetRegisterInfoInterface().GetTargetArchitecture();
switch (fpr_type)
{
case FPRType::eFPRTypeFXSAVE:
-return NativeRegisterContextLinux::ReadFPR();
+// For 32-bit inferiors on x86_32/x86_64 architectures,
+// FXSAVE area can be read using PTRACE_GETREGSET ptrace api
+// For 64-bit inferiors on x86_64 architectures,
+// FXSAVE area can be read using PTRACE_GETFPREGS ptrace api
+switch (target_arch.GetMachine ())
+{
+case llvm::Triple::x86:
+return ReadRegisterSet(&m_iovec, sizeof(m_fpr.xstate.xsave),
NT_PRXFPREG);
+case llvm::Triple::x86_64:
+return NativeRegisterContextLinux::ReadFPR();
+default:
+assert(false && "Unhandled target architecture.");
+break;
+}
case FPRType::eFPRTypeXSAVE:
return ReadRegisterSet(&m_iovec, sizeof(m_fpr.xstate.xsave),
NT_X86_XSTATE);
default:
Index:
packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
===
---
packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
+++
packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
@@ -16,7 +16,7 @@
mydir = TestBase.compute_mydir(__file__)
-@expectedFailurei386
+@expectedFailureAll(oslist=["macosx","freebsd"], archs=["i386"])
@expectedFailureWindows("llvm.org/pr24778")
@add_test_categories(['pyapi'])
def test_with_python(self):
Index: source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
===
--- source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
+++ source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
@@ -327,6 +327,9 @@
#ifndef NT_X86_XSTATE
#define NT_X86_XSTATE 0x202
#endif
+#ifndef NT_PRXFPREG
+#define NT_PRXFPREG 0x46e62b7f
+#endif
NativeRegisterContextLinux*
NativeRegisterContextLinux::CreateHostNativeRegisterContextLinux(const ArchSpec& target_arch,
@@ -868,10 +871,24 @@
NativeRegisterContextLinux_x86_64::WriteFPR()
{
const FPRType fpr_type = GetFPRType ();
+const lldb_private::ArchSpec& target_arch = GetRegisterInfoInterface().GetTargetArchitecture();
switch (fpr_type)
{
case FPRType::eFPRTypeFXSAVE:
-return NativeRegisterContextLinux::WriteFPR();
+// For 32-bit inferiors on x86_32/x86_64 architectures,
+// FXSAVE area can be written using PTRACE_SETREGSET ptrace api
+// For 64-bit inferiors on x86_64 architectures,
+// FXSAVE area can be written using PTRACE_SETFPREGS ptrace api
+switch (target_arch.GetMachine ())
+
Re: [Lldb-commits] [PATCH] D14793: Enable saving of mini dumps with lldb process save-core.
clayborg added a comment. Yep, I took care of that shortly after your commit. Repository: rL LLVM http://reviews.llvm.org/D14793 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D15067: Design building out of sources
zturner added a subscriber: zturner. zturner requested changes to this revision. zturner added a reviewer: zturner. zturner added a comment. This revision now requires changes to proceed. @labath, can you point out where clang is doing the same thing? I searched for files named `regcomp.c` for example, and only found the one copy in llvm. Duplicating code seems like a blocking issue to me, this will make the THIRD regex implementation in LLDB if we do this. Standalone build does not mean you don't need to link against LLVM libraries. Repository: rL LLVM http://reviews.llvm.org/D15067 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D14944: [LLDB][MIPS] Marking some expected failures
clayborg requested changes to this revision. clayborg added a comment. This revision now requires changes to proceed. If this is indeed a very similar test, we should fix the original test to do the right thing. Repository: rL LLVM http://reviews.llvm.org/D14944 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D14989: Fix race during process interruption
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.
One minor nit, but looks good.
Comment at: source/Target/Process.cpp:4622
@@ +4621,3 @@
+
+if (interrupt_requested) {
+if (StateIsStoppedState (internal_state, true))
Put "{" on next line
http://reviews.llvm.org/D14989
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D15046: Fix for TestNoreturnUnwind.py on i386
clayborg resigned from this revision. clayborg removed a reviewer: clayborg. clayborg added a comment. Jason Molenda should be sufficient to review this. http://reviews.llvm.org/D15046 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D15067: Design building out of sources
labath added a comment. Hmm.. you are right, of course.. I was only looking at the second version of the patch, which seems to omit the regex files. However that seems to by accidental, as they are still references in the CMake files. I agree that we should not copy the files over. @krytarowski, I assume that the problem is that the regex headers are in llvm/lib (instead of include/llvm), which means they are not installed, and you cannot include them later. Is that correct? It seems that is being done on purpose, so I guess it's a question whether lldb-mi should have been using them in the first place. We'll need to think about this more. Repository: rL LLVM http://reviews.llvm.org/D15067 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D15067: Design building out of sources
zturner added a comment. lldb-mi is including from the source tree, it should be including from the incldue tree. In other words, the incldue should be changed to: #include "llvm/Support/Regex.h" and the code should be updated to use `llvm::Regex` instead of the raw c functions. Repository: rL LLVM http://reviews.llvm.org/D15067 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D15067: Design building out of sources
labath requested changes to this revision. labath added a comment. OK, llvm seems to export the regex interface via include/llvm/Support/Regex.h. I think we should fix lldb-mi to use this interface instead, and then our problem will go away. The MI wrapper seems to be very simple, so it should not be a big problem to port it over. Repository: rL LLVM http://reviews.llvm.org/D15067 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D14952: Create new "platform process connect" command
clayborg requested changes to this revision. clayborg added a comment. This revision now requires changes to proceed. I am not sure that I like this new "platform process connect" command as it isn't really clear what this command does. "platform connect" connects to the remote platform, "process connect" connects directly to a remote GDB server that is already running. Can we just modify "platform connect" to do what "platform process connect" currently does? The code for "platform connect" would just need to detect that the platform has a process that it needs to attach do and do it. I believe this would keep the functionality that you want and keep our commands intact and a bit cleaner. http://reviews.llvm.org/D14952 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D15042: PTRACE ABI to read FXSAVE area for 32-bit inferior
clayborg resigned from this revision. clayborg removed a reviewer: clayborg. clayborg added a comment. I can't intelligently comment on low level ptrace stuff, so I will defer to others that can. http://reviews.llvm.org/D15042 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D14952: Create new "platform process connect" command
tberghammer added a comment. I decided to go with the "platform process connect" command as it connects to both to a platform and to a process instances at the same time but I agree it is not very clear. We can make this the default functionality for "platform connect" but then we have to add a new packet to the gdb protocol where lldb can ask the platform if it have to connect to a process instance or not. I am not sure if using "platform connect" will be clearer enough to give us a reason to add a new packet because in that case it will have 2 slightly different functionality based on the way lldb-platform was started on the remote target. If you prefer adding the functionality to "platform connect" then I am happy with that solution also but I am not convinced it is any better then this approach. http://reviews.llvm.org/D14952 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D14952: Create new "platform process connect" command
labath added a comment. FWIW, I like Greg's idea. The operation seems quite intuitive to me: "platform connect" connects to the platform, and if that happens to have a process ready, then it sets that up as well.. http://reviews.llvm.org/D14952 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D15067: Design building out of sources
Eugene.Zelenko added a comment. I build LLVM/Clang with LLVM_ENABLE_WARNINGS=ON, so I'll need to use llvm-config from build directory. I'm not sure how well find_program will work if path to /bin will be not added to PATH, so probably will be good idea to allow LLVM_CONFIG to be set in Cmake command line and use find_program only if LLVM_CONFIG is not set. Repository: rL LLVM http://reviews.llvm.org/D15067 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D14952: Create new "platform process connect" command
clayborg added a comment. I am fine with adding a new platform GDB remote packet that queries for a list of processes that we need to connect to after we attach. It might be nice for clients to be able to vend N number of processes that should be attached to when the platform is connected to. This could have people that implement the GDB remote platform for JTAG style devices that connected up to a chip with multiple cores. When they do "platform connect" they would be immediately connected to all cores. So I suggest adding some sort of packet that gives back a list of process IDs that we should attach to, and then attach to each of them. http://reviews.llvm.org/D14952 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D15067: Design building out of sources
krytarowski added a comment. In http://reviews.llvm.org/D15067#298701, @Eugene.Zelenko wrote: > I build LLVM/Clang with LLVM_ENABLE_WARNINGS=ON, so I'll need to use > llvm-config from build directory. I'm not sure how well find_program will > work if path to /bin will be not added to PATH, so probably > will be good idea to allow LLVM_CONFIG to be set in Cmake command line and > use find_program only if LLVM_CONFIG is not set. This should be already handled by CMake: https://cmake.org/cmake/help/v3.0/command/find_program.html Repository: rL LLVM http://reviews.llvm.org/D15067 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D14989: Fix race during process interruption
jingham added a comment.
This looks correct, I just had a few more nits...
Comment at: source/Target/Process.cpp:3827-3828
@@ -3840,9 +3826,4 @@
-// First make sure we aren't in the middle of handling an event, or we
might restart. This is pretty weak, since
-// we could just straightaway get another event. It just narrows the
window...
-m_currently_handling_event.WaitForValueEqualTo(false);
-
-
// Pause our private state thread so we can ensure no one else eats
// the stop event out from under us.
Listener halt_listener ("lldb.process.halt_listener");
Is this comment correct anymore?
Comment at: source/Target/Process.cpp:5719-5720
@@ -5746,4 +5718,4 @@
// event here. But if I do, the best thing is to Halt
and then get out of here.
-Halt();
+Halt(/*clear_thread_plans = */false, /*use_run_lock =
*/false);
}
The convention in lldb for reminding ourselves which parameters we are passing
is to do:
const bool clear_thread_plans = false;
const bool use_run_lock = false;
Halt (clear_thread_plans, use_run_lock);
http://reviews.llvm.org/D14989
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r254294 - [RS] Support RenderScript struct allocations
This revision seems to have created a hang on startup on Windows. LLDB now
hangs during global static initialization on this line:
const ConstString
RenderScriptRuntime::Element::FallbackStructName("struct");
Perhaps its an initialization order problem?
Adrian.
On Mon, Nov 30, 2015 at 2:29 AM, Ewan Crawford via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Author: ewancrawford
> Date: Mon Nov 30 04:29:49 2015
> New Revision: 254294
>
> URL: http://llvm.org/viewvc/llvm-project?rev=254294&view=rev
> Log:
> [RS] Support RenderScript struct allocations
>
> This patch adds functionality for dumping allocations of struct elements.
> This involves:
>
> + Jitting the runtime for details on all the struct fields.
>
> + Finding the name of the struct type by looking for a global variable
> of the same type, which will have been reflected back to the java host code.
>
> + Using this struct type name to pass into expression evaluation for
> pretty printing the data for the dump command.
>
> Modified:
>
> lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
>
> lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.h
>
> Modified:
> lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp?rev=254294&r1=254293&r2=254294&view=diff
>
> ==
> ---
> lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
> (original)
> +++
> lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
> Mon Nov 30 04:29:49 2015
> @@ -18,7 +18,9 @@
> #include "lldb/Core/Error.h"
> #include "lldb/Core/Log.h"
> #include "lldb/Core/PluginManager.h"
> +#include "lldb/Core/ValueObjectVariable.h"
> #include "lldb/Core/RegularExpression.h"
> +#include "lldb/DataFormatters/DumpValueObjectOptions.h"
> #include "lldb/Host/StringConvert.h"
> #include "lldb/Symbol/Symbol.h"
> #include "lldb/Symbol/Type.h"
> @@ -133,42 +135,61 @@ struct RenderScriptRuntime::ScriptDetail
> empirical_type script;
> };
>
> +// This Element class represents the Element object in RS,
> +// defining the type associated with an Allocation.
> +struct RenderScriptRuntime::Element
> +{
> +// Taken from rsDefines.h
> +enum DataKind
> +{
> +RS_KIND_USER,
> +RS_KIND_PIXEL_L = 7,
> +RS_KIND_PIXEL_A,
> +RS_KIND_PIXEL_LA,
> +RS_KIND_PIXEL_RGB,
> +RS_KIND_PIXEL_RGBA,
> +RS_KIND_PIXEL_DEPTH,
> +RS_KIND_PIXEL_YUV,
> +RS_KIND_INVALID = 100
> +};
> +
> +// Taken from rsDefines.h
> +enum DataType
> +{
> +RS_TYPE_NONE = 0,
> +RS_TYPE_FLOAT_16,
> +RS_TYPE_FLOAT_32,
> +RS_TYPE_FLOAT_64,
> +RS_TYPE_SIGNED_8,
> +RS_TYPE_SIGNED_16,
> +RS_TYPE_SIGNED_32,
> +RS_TYPE_SIGNED_64,
> +RS_TYPE_UNSIGNED_8,
> +RS_TYPE_UNSIGNED_16,
> +RS_TYPE_UNSIGNED_32,
> +RS_TYPE_UNSIGNED_64,
> +RS_TYPE_BOOLEAN
> +};
> +
> +std::vector children; // Child Element
> fields for structs
> +empirical_type element_ptr;// Pointer to
> the RS Element of the Type
> +empirical_type type; // Type of each
> data pointer stored by the allocation
> +empirical_type type_kind; // Defines pixel
> type if Allocation is created from an image
> +empirical_type type_vec_size; // Vector size
> of each data point, e.g '4' for uchar4
> +empirical_type field_count;// Number of
> Subelements
> +empirical_type datum_size; // Size of a
> single Element with padding
> +empirical_type padding;// Number of
> padding bytes
> +empirical_type array_size; // Number of
> items in array, only needed for strucrs
> +ConstString type_name; // Name of type,
> only needed for structs
> +
> +static const ConstString FallbackStructName; // Print this as
> the type name of a struct Element
> + // If we can't
> resolve the actual struct name
> +};
> +
> // This AllocationDetails class collects data associated with a single
> // allocation instance.
> struct RenderScriptRuntime::AllocationDetails
> {
> - // Taken from rsDefines.h
> - enum DataKind
> - {
> - RS_KIND_USER,
> - RS_KIND_PIXEL_L = 7,
> - RS_KIND_PIXEL_A,
> - RS_KIND_PIXEL_LA,
> - RS_KIND_PIXEL_RGB,
> - RS_KIND_PIXEL_RGBA,
> - RS_KIND_PIXEL_DEPTH,
> - RS_KIND_PIXEL_YUV,
> - RS_KIND_INVALID = 100
>
Re: [Lldb-commits] [PATCH] D15067: Design building out of sources
Eugene.Zelenko added a comment. In http://reviews.llvm.org/D15067#298830, @krytarowski wrote: > In http://reviews.llvm.org/D15067#298701, @Eugene.Zelenko wrote: > > > I build LLVM/Clang with LLVM_ENABLE_WARNINGS=ON, so I'll need to use > > llvm-config from build directory. I'm not sure how well find_program will > > work if path to /bin will be not added to PATH, so > > probably will be good idea to allow LLVM_CONFIG to be set in Cmake command > > line and use find_program only if LLVM_CONFIG is not set. > > > This should be already handled by CMake: > https://cmake.org/cmake/help/v3.0/command/find_program.html But it's necessary to pass path from CMake command line argument to find_program after PATHS. Another problem if default OS location (if Clang installed and of old version) will be returned instead of build one. Repository: rL LLVM http://reviews.llvm.org/D15067 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D15092: Fix hang in global static initialization
amccarth created this revision.
amccarth added reviewers: EwanCrawford, zturner.
amccarth added a subscriber: lldb-commits.
A previous patch introduced a global static ConstString instance. On Windows,
this results in a hang because constructing the string pool appears to depend
on other globals which haven't yet been initialized.
All other instances of static ConstStrings I could find were function static,
so I modified the code to use a static function.
http://reviews.llvm.org/D15092
Files:
source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
Index:
source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
===
---
source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
+++
source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
@@ -182,7 +182,7 @@
empirical_type array_size; // Number of items in
array, only needed for strucrs
ConstString type_name; // Name of type, only
needed for structs
-static const ConstString FallbackStructName; // Print this as the
type name of a struct Element
+static const ConstString &GetFallbackStructName(); // Print this as the
type name of a struct Element
// If we can't
resolve the actual struct name
};
@@ -250,7 +250,13 @@
}
};
-const ConstString RenderScriptRuntime::Element::FallbackStructName("struct");
+
+const ConstString &
+RenderScriptRuntime::Element::GetFallbackStructName()
+{
+static const ConstString FallbackStructName("struct");
+return FallbackStructName;
+}
unsigned int RenderScriptRuntime::AllocationDetails::ID = 1;
@@ -1629,7 +1635,7 @@
if (!elem.type_name.IsEmpty()) // Name already set
return;
else
-elem.type_name = Element::FallbackStructName; // Default type name if
we don't succeed
+elem.type_name = Element::GetFallbackStructName(); // Default type
name if we don't succeed
// Find all the global variables from the script rs modules
VariableList variable_list;
@@ -2428,7 +2434,7 @@
{
strm.Printf("\n(%u, %u, %u) = ", x, y, z);
if ((type == Element::RS_TYPE_NONE) &&
(alloc->element.children.size() > 0) &&
-(alloc->element.type_name != Element::FallbackStructName))
+(alloc->element.type_name !=
Element::GetFallbackStructName()))
{
// Here we are dumping an Element of struct type.
// This is done using expression evaluation with the name
of the struct type and pointer to element.
Index: source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
===
--- source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
+++ source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
@@ -182,7 +182,7 @@
empirical_type array_size; // Number of items in array, only needed for strucrs
ConstString type_name; // Name of type, only needed for structs
-static const ConstString FallbackStructName; // Print this as the type name of a struct Element
+static const ConstString &GetFallbackStructName(); // Print this as the type name of a struct Element
// If we can't resolve the actual struct name
};
@@ -250,7 +250,13 @@
}
};
-const ConstString RenderScriptRuntime::Element::FallbackStructName("struct");
+
+const ConstString &
+RenderScriptRuntime::Element::GetFallbackStructName()
+{
+static const ConstString FallbackStructName("struct");
+return FallbackStructName;
+}
unsigned int RenderScriptRuntime::AllocationDetails::ID = 1;
@@ -1629,7 +1635,7 @@
if (!elem.type_name.IsEmpty()) // Name already set
return;
else
-elem.type_name = Element::FallbackStructName; // Default type name if we don't succeed
+elem.type_name = Element::GetFallbackStructName(); // Default type name if we don't succeed
// Find all the global variables from the script rs modules
VariableList variable_list;
@@ -2428,7 +2434,7 @@
{
strm.Printf("\n(%u, %u, %u) = ", x, y, z);
if ((type == Element::RS_TYPE_NONE) && (alloc->element.children.size() > 0) &&
-(alloc->element.type_name != Element::FallbackStructName))
+(alloc->element.type_name != Element::GetFallbackStructName()))
{
// Here we are dumping an Element of struct type.
// This is done using expression evalua
Re: [Lldb-commits] [PATCH] D15092: Fix hang in global static initialization
zturner added inline comments. Comment at: source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp:185 @@ -184,3 +184,3 @@ -static const ConstString FallbackStructName; // Print this as the type name of a struct Element // If we can't resolve the actual struct name I wonder about returning this by reference. It seems like by convention we usually pass `ConstString`s around by value. http://reviews.llvm.org/D15092 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D15092: Fix hang in global static initialization
amccarth added inline comments. Comment at: source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp:185 @@ -184,3 +184,3 @@ -static const ConstString FallbackStructName; // Print this as the type name of a struct Element // If we can't resolve the actual struct name zturner wrote: > I wonder about returning this by reference. It seems like by convention we > usually pass `ConstString`s around by value. I was following the pattern used elsewhere, like Breakpoint::BreakpointEventData::GetFlavorString. http://reviews.llvm.org/D15092 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D15092: Fix hang in global static initialization
zturner accepted this revision. zturner added a comment. This revision is now accepted and ready to land. Ahh ok if there's already precedent for returning by reference then it's fine. http://reviews.llvm.org/D15092 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r254338 - Fix hang in global static initialization
Author: amccarth
Date: Mon Nov 30 16:18:43 2015
New Revision: 254338
URL: http://llvm.org/viewvc/llvm-project?rev=254338&view=rev
Log:
Fix hang in global static initialization
Differential Revision: http://reviews.llvm.org/D15092
Modified:
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
Modified:
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp?rev=254338&r1=254337&r2=254338&view=diff
==
---
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
(original)
+++
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
Mon Nov 30 16:18:43 2015
@@ -182,7 +182,7 @@ struct RenderScriptRuntime::Element
empirical_type array_size; // Number of items in
array, only needed for strucrs
ConstString type_name; // Name of type, only
needed for structs
-static const ConstString FallbackStructName; // Print this as the
type name of a struct Element
+static const ConstString &GetFallbackStructName(); // Print this as the
type name of a struct Element
// If we can't
resolve the actual struct name
};
@@ -250,7 +250,13 @@ struct RenderScriptRuntime::AllocationDe
}
};
-const ConstString RenderScriptRuntime::Element::FallbackStructName("struct");
+
+const ConstString &
+RenderScriptRuntime::Element::GetFallbackStructName()
+{
+static const ConstString FallbackStructName("struct");
+return FallbackStructName;
+}
unsigned int RenderScriptRuntime::AllocationDetails::ID = 1;
@@ -1629,7 +1635,7 @@ RenderScriptRuntime::FindStructTypeName(
if (!elem.type_name.IsEmpty()) // Name already set
return;
else
-elem.type_name = Element::FallbackStructName; // Default type name if
we don't succeed
+elem.type_name = Element::GetFallbackStructName(); // Default type
name if we don't succeed
// Find all the global variables from the script rs modules
VariableList variable_list;
@@ -2428,7 +2434,7 @@ RenderScriptRuntime::DumpAllocation(Stre
{
strm.Printf("\n(%u, %u, %u) = ", x, y, z);
if ((type == Element::RS_TYPE_NONE) &&
(alloc->element.children.size() > 0) &&
-(alloc->element.type_name != Element::FallbackStructName))
+(alloc->element.type_name !=
Element::GetFallbackStructName()))
{
// Here we are dumping an Element of struct type.
// This is done using expression evaluation with the name
of the struct type and pointer to element.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D15092: Fix hang in global static initialization
This revision was automatically updated to reflect the committed changes.
Closed by commit rL254338: Fix hang in global static initialization (authored
by amccarth).
Changed prior to commit:
http://reviews.llvm.org/D15092?vs=41433&id=41435#toc
Repository:
rL LLVM
http://reviews.llvm.org/D15092
Files:
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
Index:
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
===
---
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
+++
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
@@ -182,7 +182,7 @@
empirical_type array_size; // Number of items in
array, only needed for strucrs
ConstString type_name; // Name of type, only
needed for structs
-static const ConstString FallbackStructName; // Print this as the
type name of a struct Element
+static const ConstString &GetFallbackStructName(); // Print this as the
type name of a struct Element
// If we can't
resolve the actual struct name
};
@@ -250,7 +250,13 @@
}
};
-const ConstString RenderScriptRuntime::Element::FallbackStructName("struct");
+
+const ConstString &
+RenderScriptRuntime::Element::GetFallbackStructName()
+{
+static const ConstString FallbackStructName("struct");
+return FallbackStructName;
+}
unsigned int RenderScriptRuntime::AllocationDetails::ID = 1;
@@ -1629,7 +1635,7 @@
if (!elem.type_name.IsEmpty()) // Name already set
return;
else
-elem.type_name = Element::FallbackStructName; // Default type name if
we don't succeed
+elem.type_name = Element::GetFallbackStructName(); // Default type
name if we don't succeed
// Find all the global variables from the script rs modules
VariableList variable_list;
@@ -2428,7 +2434,7 @@
{
strm.Printf("\n(%u, %u, %u) = ", x, y, z);
if ((type == Element::RS_TYPE_NONE) &&
(alloc->element.children.size() > 0) &&
-(alloc->element.type_name != Element::FallbackStructName))
+(alloc->element.type_name !=
Element::GetFallbackStructName()))
{
// Here we are dumping an Element of struct type.
// This is done using expression evaluation with the name
of the struct type and pointer to element.
Index: lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
===
--- lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
+++ lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
@@ -182,7 +182,7 @@
empirical_type array_size; // Number of items in array, only needed for strucrs
ConstString type_name; // Name of type, only needed for structs
-static const ConstString FallbackStructName; // Print this as the type name of a struct Element
+static const ConstString &GetFallbackStructName(); // Print this as the type name of a struct Element
// If we can't resolve the actual struct name
};
@@ -250,7 +250,13 @@
}
};
-const ConstString RenderScriptRuntime::Element::FallbackStructName("struct");
+
+const ConstString &
+RenderScriptRuntime::Element::GetFallbackStructName()
+{
+static const ConstString FallbackStructName("struct");
+return FallbackStructName;
+}
unsigned int RenderScriptRuntime::AllocationDetails::ID = 1;
@@ -1629,7 +1635,7 @@
if (!elem.type_name.IsEmpty()) // Name already set
return;
else
-elem.type_name = Element::FallbackStructName; // Default type name if we don't succeed
+elem.type_name = Element::GetFallbackStructName(); // Default type name if we don't succeed
// Find all the global variables from the script rs modules
VariableList variable_list;
@@ -2428,7 +2434,7 @@
{
strm.Printf("\n(%u, %u, %u) = ", x, y, z);
if ((type == Element::RS_TYPE_NONE) && (alloc->element.children.size() > 0) &&
-(alloc->element.type_name != Element::FallbackStructName))
+(alloc->element.type_name != Element::GetFallbackStructName()))
{
// Here we are dumping an Element of struct type.
// This is done using expression evaluation with the name of the struct type and pointer to element.
___
lldb-com
[Lldb-commits] [lldb] r254340 - Have swig_bot actually run swig, and send back the output.
Author: zturner
Date: Mon Nov 30 16:31:13 2015
New Revision: 254340
URL: http://llvm.org/viewvc/llvm-project?rev=254340&view=rev
Log:
Have swig_bot actually run swig, and send back the output.
Added:
lldb/trunk/scripts/swig_bot_lib/remote.py
- copied, changed from r254338, lldb/trunk/scripts/swig_bot_lib/config.py
Removed:
lldb/trunk/scripts/swig_bot_lib/config.py
Modified:
lldb/trunk/scripts/swig_bot_lib/client.py
lldb/trunk/scripts/swig_bot_lib/local.py
lldb/trunk/scripts/swig_bot_lib/server.py
Modified: lldb/trunk/scripts/swig_bot_lib/client.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/swig_bot_lib/client.py?rev=254340&r1=254339&r2=254340&view=diff
==
--- lldb/trunk/scripts/swig_bot_lib/client.py (original)
+++ lldb/trunk/scripts/swig_bot_lib/client.py Mon Nov 30 16:31:13 2015
@@ -11,6 +11,7 @@ from __future__ import print_function
# Python modules
import argparse
+import io
import logging
import os
import socket
@@ -23,8 +24,8 @@ from lldbsuite.support import fs
from lldbsuite.support import sockutil
# package imports
-from . import config
from . import local
+from . import remote
default_ip = "127.0.0.1"
default_port = 8537
@@ -152,21 +153,32 @@ def run(args):
if not os.path.isfile(options.swig_executable):
logging.error("Swig executable '{}' does not exist."
.format(options.swig_executable))
-gen_options = local.GenOptions()
-gen_options.languages = options.languages
-gen_options.src_root = options.src_root
-gen_options.target_dir = options.target_dir
-gen_options.swig_executable = options.swig_executable
-local.generate(gen_options)
+config = local.LocalConfig()
+config.languages = options.languages
+config.src_root = options.src_root
+config.target_dir = options.target_dir
+config.swig_executable = options.swig_executable
+local.generate(config)
else:
logging.info("swig bot client using remote generation with server '{}'"
.format(options.remote))
connection = None
try:
-config_json = config.generate_config_json(options)
-packed_input = local.pack_archive(config_json, options)
+config = remote.generate_config(options.languages)
+logging.debug("Generated config json {}".format(config))
+inputs = [("include/lldb", ".h"),
+ ("include/lldb/API", ".h"),
+ ("scripts", ".swig"),
+ ("scripts/Python", ".swig"),
+ ("scripts/interface", ".i")]
+zip_data = io.BytesIO()
+packed_input = local.pack_archive(zip_data, options.src_root,
inputs)
+logging.info("(null) -> config.json")
+packed_input.writestr("config.json", config)
+packed_input.close()
+
connection = establish_remote_connection(options.remote)
-response = transmit_data(connection, packed_input)
+response = transmit_data(connection, zip_data.getvalue())
logging.debug("Received {} byte response.".format(len(response)))
finally:
if connection is not None:
Removed: lldb/trunk/scripts/swig_bot_lib/config.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/swig_bot_lib/config.py?rev=254339&view=auto
==
--- lldb/trunk/scripts/swig_bot_lib/config.py (original)
+++ lldb/trunk/scripts/swig_bot_lib/config.py (removed)
@@ -1,31 +0,0 @@
-#!/usr/bin/env python
-
-"""
-Shared functionality used by `client` and `server` when dealing with
-configuration data
-"""
-
-# Future imports
-from __future__ import absolute_import
-from __future__ import print_function
-
-# Python modules
-import json
-import logging
-import os
-import socket
-import struct
-import sys
-
-# LLDB modules
-import use_lldb_suite
-
-# package imports
-from . import local
-
-def generate_config_json(options):
-config = {"languages": options.languages}
-return json.dumps(config)
-
-def parse_config_json(option_json):
-return json.loads(option_json)
Modified: lldb/trunk/scripts/swig_bot_lib/local.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/swig_bot_lib/local.py?rev=254340&r1=254339&r2=254340&view=diff
==
--- lldb/trunk/scripts/swig_bot_lib/local.py (original)
+++ lldb/trunk/scripts/swig_bot_lib/local.py Mon Nov 30 16:31:13 2015
@@ -23,34 +23,32 @@ import zipfile
# LLDB modules
import use_lldb_suite
-class GenOptions(object):
+# Package imports
+from lldbsuite.support import fs
+
+class LocalConfig(object):
src_root = None
target_dir = None
languages = None
swig_executable = None
[Lldb-commits] [lldb] r254341 - Unpack the output on the client, completing the cycle.
Author: zturner
Date: Mon Nov 30 16:31:24 2015
New Revision: 254341
URL: http://llvm.org/viewvc/llvm-project?rev=254341&view=rev
Log:
Unpack the output on the client, completing the cycle.
Modified:
lldb/trunk/scripts/swig_bot_lib/client.py
lldb/trunk/scripts/swig_bot_lib/local.py
lldb/trunk/scripts/swig_bot_lib/remote.py
lldb/trunk/scripts/swig_bot_lib/server.py
Modified: lldb/trunk/scripts/swig_bot_lib/client.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/swig_bot_lib/client.py?rev=254341&r1=254340&r2=254341&view=diff
==
--- lldb/trunk/scripts/swig_bot_lib/client.py (original)
+++ lldb/trunk/scripts/swig_bot_lib/client.py Mon Nov 30 16:31:24 2015
@@ -133,7 +133,7 @@ def establish_remote_connection(ip_port)
logging.info("Connection established...")
return s
-def transmit_data(connection, packed_input):
+def transmit_request(connection, packed_input):
logging.info("Sending {} bytes of compressed data."
.format(len(packed_input)))
connection.sendall(struct.pack("!I", len(packed_input)))
@@ -144,6 +144,35 @@ def transmit_data(connection, packed_inp
response = sockutil.recvall(connection, response_len)
return response
+def handle_response(options, connection, response):
+logging.debug("Received {} byte response.".format(len(response)))
+logging.debug("Creating output directory {}"
+.format(options.target_dir))
+os.makedirs(options.target_dir, exist_ok=True)
+
+logging.info("Unpacking response archive into {}"
+.format(options.target_dir))
+local.unpack_archive(options.target_dir, response)
+response_file_path = os.path.normpath(
+os.path.join(options.target_dir, "swig_output.json"))
+if not os.path.isfile(response_file_path):
+logging.error("Response file '{}' does not exist."
+.format(response_file_path))
+return
+try:
+response = remote.deserialize_response_status(
+io.open(response_file_path))
+if response[0] != 0:
+logging.error("An error occurred during generation. Status={}"
+.format(response[0]))
+logging.error(response[1])
+else:
+logging.info("SWIG generation successful.")
+if len(response[1]) > 0:
+logging.info(response[1])
+finally:
+os.unlink(response_file_path)
+
def run(args):
options = process_args(args)
@@ -176,10 +205,9 @@ def run(args):
logging.info("(null) -> config.json")
packed_input.writestr("config.json", config)
packed_input.close()
-
connection = establish_remote_connection(options.remote)
-response = transmit_data(connection, zip_data.getvalue())
-logging.debug("Received {} byte response.".format(len(response)))
+response = transmit_request(connection, zip_data.getvalue())
+handle_response(options, connection, response)
finally:
if connection is not None:
connection.close()
\ No newline at end of file
Modified: lldb/trunk/scripts/swig_bot_lib/local.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/swig_bot_lib/local.py?rev=254341&r1=254340&r2=254341&view=diff
==
--- lldb/trunk/scripts/swig_bot_lib/local.py (original)
+++ lldb/trunk/scripts/swig_bot_lib/local.py Mon Nov 30 16:31:24 2015
@@ -44,44 +44,45 @@ def pack_archive(bytes_io, src_root, fil
except RuntimeError:
zip_file = zipfile.ZipFile(bytes_io, mode='w',
compression=zipfile.ZIP_STORED)
+archive_entries = []
+if filters is not None:
+def filter_func(t):
+subfolder = t[0]
+ext = t[1]
+full_path = os.path.normpath(os.path.join(src_root, subfolder))
+candidates = [os.path.normpath(os.path.join(full_path, f))
+ for f in os.listdir(full_path)]
+actual = filter(
+lambda f : os.path.isfile(f) and os.path.splitext(f)[1] == ext,
+candidates)
+return (subfolder, map(lambda f : os.path.basename(f), actual))
+archive_entries = map(filter_func, filters)
+else:
+for (root, dirs, files) in os.walk(src_root):
+logging.debug("Adding files {} from directory {} to output package"
+ .format(files, root))
+if len(files) > 0:
+rel_root = os.path.relpath(root, src_root)
+archive_entries.append((rel_root, files))
-def filter_func(t):
-subfolder = t[0]
-ext = t[1]
-full_path = os.path.normpath(os.path.join(src_root, subfolder))
-candidates = [os.path.normpath(os.path.join(f
[Lldb-commits] [lldb] r254349 - Fix a bug where one-lining display of child values would ignore the user's choice of format
Author: enrico Date: Mon Nov 30 18:04:52 2015 New Revision: 254349 URL: http://llvm.org/viewvc/llvm-project?rev=254349&view=rev Log: Fix a bug where one-lining display of child values would ignore the user's choice of format Modified: lldb/trunk/source/DataFormatters/ValueObjectPrinter.cpp Modified: lldb/trunk/source/DataFormatters/ValueObjectPrinter.cpp URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/DataFormatters/ValueObjectPrinter.cpp?rev=254349&r1=254348&r2=254349&view=diff == --- lldb/trunk/source/DataFormatters/ValueObjectPrinter.cpp (original) +++ lldb/trunk/source/DataFormatters/ValueObjectPrinter.cpp Mon Nov 30 18:04:52 2015 @@ -839,7 +839,7 @@ ValueObjectPrinter::PrintChildrenOneLine } child_sp->DumpPrintableRepresentation(*m_stream, ValueObject::eValueObjectRepresentationStyleSummary, - lldb::eFormatInvalid, + m_options.m_format, ValueObject::ePrintableRepresentationSpecialCasesDisable); } } ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] Buildbot numbers for week of 11/22/2015 - 11/28/2015
Hello everyone, Below are some buildbot numbers for the last week of 11/22/2015 - 11/28/2015. Thanks Galina Top 10 fastest builders(not docs): lldb-amd64-ninja-freebsd11 clang-bpf-build llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03 sanitizer-windows libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx1z libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14 libcxx-libcxxabi-x86_64-linux-ubuntu-unstable-abi llvm-hexagon-elf 10 most slow builders: clang-native-arm-lnt-perf clang-native-aarch64-full clang-atom-d525-fedora clang-cmake-thumbv7-a15-full-sh perf-x86_64-penryn-O3 perf-x86_64-penryn-O3-polly perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only clang-cmake-armv7-a15-selfhost-neon llvm-mips-linux sanitizer-x86_64-linux-bootstrap Number of commits by project: project | commits --- llvm | 218 cfe |67 compiler-rt |33 lld |30 lldb |23 polly | 8 clang-tools-extra | 7 libcxx| 4 llgo | 1 --- 391 Number of completed builds, failed builds and average build time for successful builds per active builder: buildername | completed | failed | time - clang-aarch64-lnt | 56 | 3 | 02:31:36 clang-atom-d525-fedora| 21 | 5 | 08:06:27 clang-atom-d525-fedora-rel| 80 | 12 | 01:31:08 clang-bpf-build |239 | 47 | 00:02:59 clang-cmake-aarch64-42vma |214 | 80 | 00:16:33 clang-cmake-aarch64-full | 1 || 03:17:48 clang-cmake-aarch64-quick |178 | 64 | 00:22:56 clang-cmake-armv7-a15 |170 | 9 | 00:27:14 clang-cmake-armv7-a15-full|135 | 31 | 00:47:54 clang-cmake-armv7-a15-selfhost| 41 | 17 | 04:13:48 clang-cmake-armv7-a15-selfhost-neon | 38 | 18 | 05:04:39 clang-cmake-mips |158 | 50 | 00:27:47 clang-cmake-thumbv7-a15 |157 | 22 | 00:27:57 clang-cmake-thumbv7-a15-full-sh | 28 | 12 | 06:13:18 clang-hexagon-elf |139 | 12 | 00:16:00 clang-native-aarch64-full | 16 | 5 | 08:14:29 clang-native-arm-lnt |107 | 17 | 01:08:19 clang-native-arm-lnt-perf | 25 | 11 | 08:40:48 clang-ppc64-elf-linux |110 | 3 | 01:01:45 clang-ppc64-elf-linux2| 83 | 14 | 01:31:11 clang-sphinx-docs |111 || 00:00:20 clang-x64-ninja-win7 |158 | 28 | 00:34:54 clang-x86-win2008-selfhost|110 | 17 | 01:02:17 clang-x86_64-darwin13-cross-arm |197 | 5 | 00:19:48 clang-x86_64-darwin13-cross-mingw32 |184 | 5 | 00:23:16 clang-x86_64-debian-fast |137 | 24 | 00:10:32 clang-x86_64-linux-abi-test |243 | 3 | 00:18:45 clang-x86_64-linux-selfhost-modules |212 | 45 | 00:15:08 clang-x86_64-ubuntu-gdb-75|131 | 45 | 00:49:38 libcxx-libcxxabi-arm-linux| 4 || 01:09:42 libcxx-libcxxabi-singlethreaded-x86_64-linux-debian | 4 || 00:08:08 libcxx-libcxxabi-x86_64-linux-debian | 4 || 00:08:33 libcxx-libcxxabi-x86_64-linux-debian-noexceptions | 4 || 00:08:03 libcxx-libcxxabi-x86_64-linux-ubuntu-asan | 4 || 00:08:25 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03
Re: [Lldb-commits] Buildbot numbers for week of 11/22/2015 - 11/28/2015
Thanks for tracking these results, Galina I think it might be better to send these to the -dev lists, rather than the -commits lists, but I'm not sure what other people think on that. On Mon, Nov 30, 2015 at 4:17 PM, Galina Kistanova via cfe-commits < cfe-comm...@lists.llvm.org> wrote: > Hello everyone, > > Below are some buildbot numbers for the last week of 11/22/2015 - > 11/28/2015. > > Thanks > > Galina > > > > Top 10 fastest builders(not docs): > > lldb-amd64-ninja-freebsd11 > clang-bpf-build > llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast > libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03 > sanitizer-windows > libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11 > libcxx-libcxxabi-x86_64-linux-ubuntu-cxx1z > libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14 > libcxx-libcxxabi-x86_64-linux-ubuntu-unstable-abi > llvm-hexagon-elf > > > > 10 most slow builders: > > clang-native-arm-lnt-perf > clang-native-aarch64-full > clang-atom-d525-fedora > clang-cmake-thumbv7-a15-full-sh > perf-x86_64-penryn-O3 > perf-x86_64-penryn-O3-polly > perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only > clang-cmake-armv7-a15-selfhost-neon > llvm-mips-linux > sanitizer-x86_64-linux-bootstrap > > > > Number of commits by project: > > project | commits > --- > llvm | 218 > cfe |67 > compiler-rt |33 > lld |30 > lldb |23 > polly | 8 > clang-tools-extra | 7 > libcxx| 4 > llgo | 1 > --- >391 > > > Number of completed builds, failed builds and average build time for > successful builds per active builder: > Maybe we could sort this \/ list by some ratio of failed/completed? I guess the entries with no entry in the failed column have zero failures? > > buildername | completed | > failed | time > > - > clang-aarch64-lnt | 56 > | 3 | 02:31:36 > clang-atom-d525-fedora| 21 > | 5 | 08:06:27 > clang-atom-d525-fedora-rel| 80 > | 12 | 01:31:08 > clang-bpf-build |239 > | 47 | 00:02:59 > clang-cmake-aarch64-42vma |214 > | 80 | 00:16:33 > clang-cmake-aarch64-full | 1 > || 03:17:48 > clang-cmake-aarch64-quick |178 > | 64 | 00:22:56 > clang-cmake-armv7-a15 |170 > | 9 | 00:27:14 > clang-cmake-armv7-a15-full|135 > | 31 | 00:47:54 > clang-cmake-armv7-a15-selfhost| 41 > | 17 | 04:13:48 > clang-cmake-armv7-a15-selfhost-neon | 38 > | 18 | 05:04:39 > clang-cmake-mips |158 > | 50 | 00:27:47 > clang-cmake-thumbv7-a15 |157 > | 22 | 00:27:57 > clang-cmake-thumbv7-a15-full-sh | 28 > | 12 | 06:13:18 > clang-hexagon-elf |139 > | 12 | 00:16:00 > clang-native-aarch64-full | 16 > | 5 | 08:14:29 > clang-native-arm-lnt |107 > | 17 | 01:08:19 > clang-native-arm-lnt-perf | 25 > | 11 | 08:40:48 > clang-ppc64-elf-linux |110 > | 3 | 01:01:45 > clang-ppc64-elf-linux2| 83 > | 14 | 01:31:11 > clang-sphinx-docs |111 > || 00:00:20 > clang-x64-ninja-win7 |158 > | 28 | 00:34:54 > clang-x86-win2008-selfhost|110 > | 17 | 01:02:17 > clang-x86_64-darwin13-cross-arm |197 > | 5 | 00:19:48 > clang-x86_64-darwin13-cross-mingw32 |184 > | 5 | 00:23:16 > clang-x86_64-debian-fast |137 > | 24 | 00:10:32 > clang-x86_64-linux-abi-test |243 > | 3 | 00:18:45 > clang-x86_64-linux-selfhost-modules
Re: [Lldb-commits] Buildbot numbers for week of 11/22/2015 - 11/28/2015
Hi David, Thank you for the useful suggestions, I will work on these. >I guess the entries with no entry in the failed column have zero failures? Yes. perf-x86_64-penryn-O3-polly-before-vectorizer | 31 | 31 | perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only | 31 | 27 | 05:28:12 These /\ two builders failed most of the time, but they also only ran a handful of times. I guess they're triggering off polly changes only? I wonder if they should trigger off LLVM changes too, but I'm not sure. They build on llvm changes also, but they both build for quite a long time. I think it's the reason why they do not build more. Thanks Galina On Mon, Nov 30, 2015 at 4:28 PM, David Blaikie wrote: > Thanks for tracking these results, Galina > > I think it might be better to send these to the -dev lists, rather than > the -commits lists, but I'm not sure what other people think on that. > > On Mon, Nov 30, 2015 at 4:17 PM, Galina Kistanova via cfe-commits < > cfe-comm...@lists.llvm.org> wrote: > >> Hello everyone, >> >> Below are some buildbot numbers for the last week of 11/22/2015 - >> 11/28/2015. >> >> Thanks >> >> Galina >> >> >> >> Top 10 fastest builders(not docs): >> >> lldb-amd64-ninja-freebsd11 >> clang-bpf-build >> llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast >> libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03 >> sanitizer-windows >> libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11 >> libcxx-libcxxabi-x86_64-linux-ubuntu-cxx1z >> libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14 >> libcxx-libcxxabi-x86_64-linux-ubuntu-unstable-abi >> llvm-hexagon-elf >> >> >> >> 10 most slow builders: >> >> clang-native-arm-lnt-perf >> clang-native-aarch64-full >> clang-atom-d525-fedora >> clang-cmake-thumbv7-a15-full-sh >> perf-x86_64-penryn-O3 >> perf-x86_64-penryn-O3-polly >> perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only >> clang-cmake-armv7-a15-selfhost-neon >> llvm-mips-linux >> sanitizer-x86_64-linux-bootstrap >> >> >> >> Number of commits by project: >> >> project | commits >> --- >> llvm | 218 >> cfe |67 >> compiler-rt |33 >> lld |30 >> lldb |23 >> polly | 8 >> clang-tools-extra | 7 >> libcxx| 4 >> llgo | 1 >> --- >>391 >> >> >> Number of completed builds, failed builds and average build time for >> successful builds per active builder: >> > > Maybe we could sort this \/ list by some ratio of failed/completed? > > I guess the entries with no entry in the failed column have zero failures? > > >> >> buildername | completed | >> failed | time >> >> - >> clang-aarch64-lnt | 56 >> | 3 | 02:31:36 >> clang-atom-d525-fedora| 21 >> | 5 | 08:06:27 >> clang-atom-d525-fedora-rel| 80 >> | 12 | 01:31:08 >> clang-bpf-build |239 >> | 47 | 00:02:59 >> clang-cmake-aarch64-42vma |214 >> | 80 | 00:16:33 >> clang-cmake-aarch64-full | 1 >> || 03:17:48 >> clang-cmake-aarch64-quick |178 >> | 64 | 00:22:56 >> clang-cmake-armv7-a15 |170 >> | 9 | 00:27:14 >> clang-cmake-armv7-a15-full|135 >> | 31 | 00:47:54 >> clang-cmake-armv7-a15-selfhost| 41 >> | 17 | 04:13:48 >> clang-cmake-armv7-a15-selfhost-neon | 38 >> | 18 | 05:04:39 >> clang-cmake-mips |158 >> | 50 | 00:27:47 >> clang-cmake-thumbv7-a15 |157 >> | 22 | 00:27:57 >> clang-cmake-thumbv7-a15-full-sh | 28 >> | 12 | 06:13:18 >> clang-hexagon-elf |139 >> | 12 | 00:16:00 >> clang-native-aarch64-full | 16 >> | 5 | 08:14:29 >> clang-native-arm-lnt |107 >> | 17 | 01:08:19 >> clang-native-arm-lnt-perf | 25 >> | 11 | 08:40:48 >> clang-ppc64-elf-linux |11
Re: [Lldb-commits] Buildbot numbers for week of 11/22/2015 - 11/28/2015
On Mon, Nov 30, 2015 at 5:00 PM, Galina Kistanova wrote: > Hi David, > > Thank you for the useful suggestions, I will work on these. > > >I guess the entries with no entry in the failed column have zero failures? > Yes. > > perf-x86_64-penryn-O3-polly-before-vectorizer | > 31 | 31 | > perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only | > 31 | 27 | 05:28:12 > > These /\ two builders failed most of the time, but they also only ran a > handful of times. I guess they're triggering off polly changes only? I > wonder if they should trigger off LLVM changes too, but I'm not sure. > > They build on llvm changes also, but they both build for quite a long > time. I think it's the reason why they do not build more. > Ah, OK - so the other suggestions might help demonstrate/understand that behavior better. Tobias - any idea why these builders are /quite/ so slow & whether they could be improved? With large blame lists that come from a small number of slaves on a slow builder task it makes them hard to action. Are they useful to you? - Dave > > Thanks > > Galina > > > > > On Mon, Nov 30, 2015 at 4:28 PM, David Blaikie wrote: > >> Thanks for tracking these results, Galina >> >> I think it might be better to send these to the -dev lists, rather than >> the -commits lists, but I'm not sure what other people think on that. >> >> On Mon, Nov 30, 2015 at 4:17 PM, Galina Kistanova via cfe-commits < >> cfe-comm...@lists.llvm.org> wrote: >> >>> Hello everyone, >>> >>> Below are some buildbot numbers for the last week of 11/22/2015 - >>> 11/28/2015. >>> >>> Thanks >>> >>> Galina >>> >>> >>> >>> Top 10 fastest builders(not docs): >>> >>> lldb-amd64-ninja-freebsd11 >>> clang-bpf-build >>> llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast >>> libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03 >>> sanitizer-windows >>> libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11 >>> libcxx-libcxxabi-x86_64-linux-ubuntu-cxx1z >>> libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14 >>> libcxx-libcxxabi-x86_64-linux-ubuntu-unstable-abi >>> llvm-hexagon-elf >>> >>> >>> >>> 10 most slow builders: >>> >>> clang-native-arm-lnt-perf >>> clang-native-aarch64-full >>> clang-atom-d525-fedora >>> clang-cmake-thumbv7-a15-full-sh >>> perf-x86_64-penryn-O3 >>> perf-x86_64-penryn-O3-polly >>> perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only >>> clang-cmake-armv7-a15-selfhost-neon >>> llvm-mips-linux >>> sanitizer-x86_64-linux-bootstrap >>> >>> >>> >>> Number of commits by project: >>> >>> project | commits >>> --- >>> llvm | 218 >>> cfe |67 >>> compiler-rt |33 >>> lld |30 >>> lldb |23 >>> polly | 8 >>> clang-tools-extra | 7 >>> libcxx| 4 >>> llgo | 1 >>> --- >>>391 >>> >>> >>> Number of completed builds, failed builds and average build time for >>> successful builds per active builder: >>> >> >> Maybe we could sort this \/ list by some ratio of failed/completed? >> >> I guess the entries with no entry in the failed column have zero failures? >> >> >>> >>> buildername | completed >>> | failed | time >>> >>> - >>> clang-aarch64-lnt | 56 >>> | 3 | 02:31:36 >>> clang-atom-d525-fedora| 21 >>> | 5 | 08:06:27 >>> clang-atom-d525-fedora-rel| 80 >>> | 12 | 01:31:08 >>> clang-bpf-build |239 >>> | 47 | 00:02:59 >>> clang-cmake-aarch64-42vma |214 >>> | 80 | 00:16:33 >>> clang-cmake-aarch64-full | 1 >>> || 03:17:48 >>> clang-cmake-aarch64-quick |178 >>> | 64 | 00:22:56 >>> clang-cmake-armv7-a15 |170 >>> | 9 | 00:27:14 >>> clang-cmake-armv7-a15-full|135 >>> | 31 | 00:47:54 >>> clang-cmake-armv7-a15-selfhost| 41 >>> | 17 | 04:13:48 >>> clang-cmake-armv7-a15-selfhost-neon | 38 >>> | 18 | 05:04:39 >>> clang-cmake-mips |158 >>> | 50 | 00:27:47 >>> clang-cmake-thumbv7-a15 |157 >>> | 22 | 00:27:57 >>> clang-cmake-thumbv7-a15-full-sh
Re: [Lldb-commits] [PATCH] D15046: Fix for TestNoreturnUnwind.py on i386
jasonmolenda added a comment. Hi Ravitheja, thanks for putting together a patch, I'm probably the best person to look at this. I'm not sure I understand the failure mode. When built with clang, this vdso routine does not preserve the frame pointer register (rbp), right? If lldb knows the start address of the function, lldb should be able to use the assembly language inspection to get the correct backtrace, even for frameless code. I'm afraid this change would (ultimately) make lldb fall back to the architectural default unwind plan - and if it's in a frameless function, that's not correct. When the arch default unwind plan is used in a frameless function, you'll usually end up skipping the caller stack frame when you show the backtrace. Would it be possible to show the disassembly of the routine lldb is having problems with? Could you stop there and backtrace while (lldb) log enable lldb unwind is enabled? The logging is a little difficult to follow, but once you're used to how the unwinder works it makes pretty good sense. I don't have a system set up to get this information myself - I'd like to make sure I understand how the unwinder is failing here. Thanks! http://reviews.llvm.org/D15046 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12877: [LLDB] Switch to assembly view if source is moved
jasonmolenda added a comment. Yep, Greg said the patch is good to commit. Repository: rL LLVM http://reviews.llvm.org/D12877 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r254376 - [LLDB][MIPS] Change ARCHFLAG for MIPS
Author: jaydeep Date: Mon Nov 30 23:24:17 2015 New Revision: 254376 URL: http://llvm.org/viewvc/llvm-project?rev=254376&view=rev Log: [LLDB][MIPS] Change ARCHFLAG for MIPS SUMMARY: For MIPS, ARCH is specified without m. Reviewers: clayborg Subscribers: nitesh.jain, mohit.bhakkad, sagar, bhushan and lldb-commits Differential Revision: http://reviews.llvm.org/D14978 Modified: lldb/trunk/packages/Python/lldbsuite/test/make/Makefile.rules Modified: lldb/trunk/packages/Python/lldbsuite/test/make/Makefile.rules URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/make/Makefile.rules?rev=254376&r1=254375&r2=254376&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/make/Makefile.rules (original) +++ lldb/trunk/packages/Python/lldbsuite/test/make/Makefile.rules Mon Nov 30 23:24:17 2015 @@ -168,6 +168,9 @@ else override ARCH := override ARCHFLAG := endif + ifeq "$(findstring mips,$(ARCH))" "mips" + override ARCHFLAG := - + endif ifeq "$(SPLIT_DEBUG_SYMBOLS)" "YES" DSYM = $(EXE).debug ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D14978: [MIPS] Change ARCHFLAG for MIPS
jaydeep closed this revision. jaydeep added a comment. Closed by commit http://reviews.llvm.org/rL254376 Repository: rL LLVM http://reviews.llvm.org/D14978 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r254379 - [LLDB][MIPS] Clear bug 25194 - LLDB-Server Assertion raised when single stepping on MIPS
Author: slthakur
Date: Mon Nov 30 23:44:18 2015
New Revision: 254379
URL: http://llvm.org/viewvc/llvm-project?rev=254379&view=rev
Log:
[LLDB][MIPS] Clear bug 25194 - LLDB-Server Assertion raised when single
stepping on MIPS
This patch will clear bug 25194 - LLDB-Server Assertion raised when single
stepping on MIPS. The problem was that while emulating instructions, old and
new pc values would have garbage value in their upper 32 bits. Therefore
checking if pc was changed (old_pc == new_pc) would always return false,
because of which pc was not getting updated.
/* If we haven't changed the PC, change it here */
if (old_pc == new_pc)
{
new_pc += 4;
Context context;
return false;
}
Reviewers: tberghammer, clayborg
Subscribers: dsanders, lldb-commits, mohit.bhakkad, bhushan, jaydeep,
nitesh.jain
Differential: http://reviews.llvm.org/D14633
Modified:
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp
Modified:
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp?rev=254379&r1=254378&r2=254379&view=diff
==
---
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp
(original)
+++
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp
Mon Nov 30 23:44:18 2015
@@ -1376,6 +1376,9 @@ NativeRegisterContextLinux_mips64::DoRea
{
GPR_linux_mips regs;
::memset(®s, 0, sizeof(GPR_linux_mips));
+
+// Clear all bits in RegisterValue before writing actual value read from
ptrace to avoid garbage value in 32-bit MSB
+value.SetBytes((void *)(((unsigned char *)®s) + offset), 8,
GetByteOrder());
Error error = NativeProcessLinux::PtraceWrapper(PTRACE_GETREGS,
m_thread.GetID(), NULL, ®s, sizeof regs);
if (error.Success())
{
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D14633: [LLDB][MIPS] Clear bug 25194 - LLDB-Server Assertion raised when single stepping on MIPS
sagar closed this revision. sagar added a comment. Committed in revision 254379 Repository: rL LLVM http://reviews.llvm.org/D14633 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
