[Lldb-commits] [lldb] r246841 - SysV ABI for i386 Architecture
Author: abhishek
Date: Fri Sep 4 02:44:05 2015
New Revision: 246841
URL: http://llvm.org/viewvc/llvm-project?rev=246841&view=rev
Log:
SysV ABI for i386 Architecture
Summary:
- Capability to force return user specified values
from inside of a function on lldb command terminal
- Support for Integral, Pointer and Floating Point values
Signed-off-by: Abhishek Aggarwal
Reviewers: jingham, clayborg
Subscribers: tberghammer
Differential Revision: http://reviews.llvm.org/D12595
Modified:
lldb/trunk/source/Plugins/ABI/SysV-i386/ABISysV_i386.cpp (contents, props
changed)
Modified: lldb/trunk/source/Plugins/ABI/SysV-i386/ABISysV_i386.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ABI/SysV-i386/ABISysV_i386.cpp?rev=246841&r1=246840&r2=246841&view=diff
==
--- lldb/trunk/source/Plugins/ABI/SysV-i386/ABISysV_i386.cpp (original)
+++ lldb/trunk/source/Plugins/ABI/SysV-i386/ABISysV_i386.cpp Fri Sep 4
02:44:05 2015
@@ -418,8 +418,149 @@ Error
ABISysV_i386::SetReturnValueObject(lldb::StackFrameSP &frame_sp,
lldb::ValueObjectSP &new_value_sp)
{
Error error;
-//ToDo: Yet to be implemented
-error.SetErrorString("ABISysV_i386::SetReturnValueObject(): Not
implemented yet");
+if (!new_value_sp)
+{
+error.SetErrorString("Empty value object for return value.");
+return error;
+}
+
+CompilerType clang_type = new_value_sp->GetCompilerType();
+if (!clang_type)
+{
+error.SetErrorString ("Null clang type for return value.");
+return error;
+}
+
+const uint32_t type_flags = clang_type.GetTypeInfo ();
+Thread *thread = frame_sp->GetThread().get();
+RegisterContext *reg_ctx = thread->GetRegisterContext().get();
+DataExtractor data;
+Error data_error;
+size_t num_bytes = new_value_sp->GetData(data, data_error);
+bool register_write_successful = true;
+
+if (data_error.Fail())
+{
+error.SetErrorStringWithFormat("Couldn't convert return value to raw
data: %s", data_error.AsCString());
+return error;
+}
+
+// Following "IF ELSE" block categorizes various 'Fundamental Data Types'.
+// The terminology 'Fundamental Data Types' used here is adopted from
+// Table 2.1 of the reference document (specified on top of this file)
+
+if (type_flags & eTypeIsPointer) // 'Pointer'
+{
+if(num_bytes != sizeof(uint32_t))
+{
+error.SetErrorString("Pointer to be returned is not 4 bytes wide");
+return error;
+}
+lldb::offset_t offset = 0;
+const RegisterInfo *eax_info = reg_ctx->GetRegisterInfoByName("eax",
0);
+uint32_t raw_value = data.GetMaxU32(&offset, num_bytes);
+register_write_successful = reg_ctx->WriteRegisterFromUnsigned
(eax_info, raw_value);
+}
+else if ((type_flags & eTypeIsScalar) || (type_flags &
eTypeIsEnumeration)) //'Integral' + 'Floating Point'
+{
+lldb::offset_t offset = 0;
+const RegisterInfo *eax_info = reg_ctx->GetRegisterInfoByName("eax",
0);
+
+if (type_flags & eTypeIsInteger)// 'Integral' except enum
+{
+switch (num_bytes)
+{
+default:
+break;
+case 16:
+// For clang::BuiltinType::UInt128 & Int128
+// ToDo: Need to decide how to handle it
+break;
+case 8:
+{
+uint32_t raw_value_low = data.GetMaxU32(&offset, 4);
+const RegisterInfo *edx_info =
reg_ctx->GetRegisterInfoByName("edx", 0);
+uint32_t raw_value_high = data.GetMaxU32(&offset,
num_bytes - offset);
+register_write_successful =
(reg_ctx->WriteRegisterFromUnsigned (eax_info, raw_value_low) &&
+
reg_ctx->WriteRegisterFromUnsigned (edx_info, raw_value_high));
+break;
+}
+case 4:
+case 2:
+case 1:
+{
+uint32_t raw_value = data.GetMaxU32(&offset, num_bytes);
+register_write_successful =
reg_ctx->WriteRegisterFromUnsigned (eax_info, raw_value);
+break;
+}
+}
+}
+else if (type_flags & eTypeIsEnumeration)// handles enum
+{
+uint32_t raw_value = data.GetMaxU32(&offset, num_bytes);
+register_write_successful = reg_ctx->WriteRegisterFromUnsigned
(eax_info, raw_value);
+}
+else if (type_flags & eTypeIsFloat) // 'Floating Point'
+{
+RegisterValue st0_value, fstat_value, ftag_value;
+const RegisterInfo *st0_info =
reg_ctx->GetRegisterInfoByName("st0", 0);
+const RegisterInfo *fstat_info =
reg_
Re: [Lldb-commits] [PATCH] D12599: Only export public symbols with the cmake build.
labath added a comment. In http://reviews.llvm.org/D12599#239378, @tfiala wrote: > 13% size decrease sounds nice! Was that with a DebugAsserts build, > optimized, or what? This was a release build (-O3 -DNDEBUG). Size went down from ~58 to ~51 MB. > tfiala, on Mac OS X with this change, the liblldb.dylib went from 58468408 to > 53626572 bytes (release build). Note that this applies to the cmake build on OSX. XCode build uses this already so the size should not be affected. Repository: rL LLVM http://reviews.llvm.org/D12599 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r246842 - RenderScript pending kernel breakpoints.
Author: ewancrawford
Date: Fri Sep 4 03:56:52 2015
New Revision: 246842
URL: http://llvm.org/viewvc/llvm-project?rev=246842&view=rev
Log:
RenderScript pending kernel breakpoints.
Currently the RS breakpoint command can only find a kernel if it's in an
already loaded RS module.
This patch allows users to set pending breakpoints on RenderScript kernels
which will be loaded in the future.
Implemented by creating a RS breakpoint resolver, to limit search scope to only
RS modules.
Reviewed by: clayborg, jingham
Subscribers: lldb-commits, ADodds, domipheus
Differential Revision: http://reviews.llvm.org/D12360
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=246842&r1=246841&r2=246842&view=diff
==
---
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
(original)
+++
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
Fri Sep 4 03:56:52 2015
@@ -30,6 +30,7 @@
using namespace lldb;
using namespace lldb_private;
+using namespace lldb_renderscript;
//--
// Static Functions
@@ -44,6 +45,47 @@ RenderScriptRuntime::CreateInstance(Proc
return NULL;
}
+// Callback with a module to search for matching symbols.
+// We first check that the module contains RS kernels.
+// Then look for a symbol which matches our kernel name.
+// The breakpoint address is finally set using the address of this symbol.
+Searcher::CallbackReturn
+RSBreakpointResolver::SearchCallback(SearchFilter &filter,
+ SymbolContext &context,
+ Address*,
+ bool)
+{
+ModuleSP module = context.module_sp;
+
+if (!module)
+return Searcher::eCallbackReturnContinue;
+
+// Is this a module containing renderscript kernels?
+if (nullptr ==
module->FindFirstSymbolWithNameAndType(ConstString(".rs.info"),
eSymbolTypeData))
+return Searcher::eCallbackReturnContinue;
+
+// Attempt to set a breakpoint on the kernel name symbol within the module
library.
+// If it's not found, it's likely debug info is unavailable - try to set a
+// breakpoint on .expand.
+
+const Symbol* kernel_sym =
module->FindFirstSymbolWithNameAndType(m_kernel_name, eSymbolTypeCode);
+if (!kernel_sym)
+{
+std::string kernel_name_expanded(m_kernel_name.AsCString());
+kernel_name_expanded.append(".expand");
+kernel_sym =
module->FindFirstSymbolWithNameAndType(ConstString(kernel_name_expanded.c_str()),
eSymbolTypeCode);
+}
+
+if (kernel_sym)
+{
+Address bp_addr = kernel_sym->GetAddress();
+if (filter.AddressPasses(bp_addr))
+m_breakpoint->AddLocation(bp_addr);
+}
+
+return Searcher::eCallbackReturnContinue;
+}
+
void
RenderScriptRuntime::Initialize()
{
@@ -767,68 +809,24 @@ RenderScriptRuntime::DumpKernels(Stream
strm.IndentLess();
}
-void
-RenderScriptRuntime::AttemptBreakpointAtKernelName(Stream &strm, const char*
name, Error& error)
+void
+RenderScriptRuntime::AttemptBreakpointAtKernelName(Stream &strm, const char*
name, Error& error, TargetSP target)
{
-if (!name)
+if (!name)
{
error.SetErrorString("invalid kernel name");
return;
}
-bool kernels_found = false;
-ConstString kernel_name(name);
-for (const auto &module : m_rsmodules)
-{
-for (const auto &kernel : module->m_kernels)
-{
-if (kernel.m_name == kernel_name)
-{
-//Attempt to set a breakpoint on this symbol, within the
module library
-//If it's not found, it's likely debug info is unavailable -
set a
-//breakpoint on .expand and emit a warning.
-
-const Symbol* kernel_sym =
module->m_module->FindFirstSymbolWithNameAndType(kernel_name, eSymbolTypeCode);
-
-if (!kernel_sym)
-{
-std::string kernel_name_expanded(name);
-kernel_name_expanded.append(".expand");
-kernel_sym =
module->m_module->FindFirstSymbolWithNameAndType(ConstString(kernel_name_expanded.c_str()),
eSymbolTypeCode);
-
-if (kernel_sym)
-{
-strm.Printf("Kernel '%s' could not be found, but
expansion exists. ", name);
-
Re: [Lldb-commits] [PATCH] D12360: RenderScript pending kernel breakpoints.
This revision was automatically updated to reflect the committed changes.
Closed by commit rL246842: RenderScript pending kernel breakpoints. (authored
by EwanCrawford).
Changed prior to commit:
http://reviews.llvm.org/D12360?vs=33425&id=34018#toc
Repository:
rL LLVM
http://reviews.llvm.org/D12360
Files:
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.h
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
@@ -30,6 +30,7 @@
using namespace lldb;
using namespace lldb_private;
+using namespace lldb_renderscript;
//--
// Static Functions
@@ -44,6 +45,47 @@
return NULL;
}
+// Callback with a module to search for matching symbols.
+// We first check that the module contains RS kernels.
+// Then look for a symbol which matches our kernel name.
+// The breakpoint address is finally set using the address of this symbol.
+Searcher::CallbackReturn
+RSBreakpointResolver::SearchCallback(SearchFilter &filter,
+ SymbolContext &context,
+ Address*,
+ bool)
+{
+ModuleSP module = context.module_sp;
+
+if (!module)
+return Searcher::eCallbackReturnContinue;
+
+// Is this a module containing renderscript kernels?
+if (nullptr == module->FindFirstSymbolWithNameAndType(ConstString(".rs.info"), eSymbolTypeData))
+return Searcher::eCallbackReturnContinue;
+
+// Attempt to set a breakpoint on the kernel name symbol within the module library.
+// If it's not found, it's likely debug info is unavailable - try to set a
+// breakpoint on .expand.
+
+const Symbol* kernel_sym = module->FindFirstSymbolWithNameAndType(m_kernel_name, eSymbolTypeCode);
+if (!kernel_sym)
+{
+std::string kernel_name_expanded(m_kernel_name.AsCString());
+kernel_name_expanded.append(".expand");
+kernel_sym = module->FindFirstSymbolWithNameAndType(ConstString(kernel_name_expanded.c_str()), eSymbolTypeCode);
+}
+
+if (kernel_sym)
+{
+Address bp_addr = kernel_sym->GetAddress();
+if (filter.AddressPasses(bp_addr))
+m_breakpoint->AddLocation(bp_addr);
+}
+
+return Searcher::eCallbackReturnContinue;
+}
+
void
RenderScriptRuntime::Initialize()
{
@@ -767,68 +809,24 @@
strm.IndentLess();
}
-void
-RenderScriptRuntime::AttemptBreakpointAtKernelName(Stream &strm, const char* name, Error& error)
+void
+RenderScriptRuntime::AttemptBreakpointAtKernelName(Stream &strm, const char* name, Error& error, TargetSP target)
{
-if (!name)
+if (!name)
{
error.SetErrorString("invalid kernel name");
return;
}
-bool kernels_found = false;
-ConstString kernel_name(name);
-for (const auto &module : m_rsmodules)
-{
-for (const auto &kernel : module->m_kernels)
-{
-if (kernel.m_name == kernel_name)
-{
-//Attempt to set a breakpoint on this symbol, within the module library
-//If it's not found, it's likely debug info is unavailable - set a
-//breakpoint on .expand and emit a warning.
-
-const Symbol* kernel_sym = module->m_module->FindFirstSymbolWithNameAndType(kernel_name, eSymbolTypeCode);
-
-if (!kernel_sym)
-{
-std::string kernel_name_expanded(name);
-kernel_name_expanded.append(".expand");
-kernel_sym = module->m_module->FindFirstSymbolWithNameAndType(ConstString(kernel_name_expanded.c_str()), eSymbolTypeCode);
-
-if (kernel_sym)
-{
-strm.Printf("Kernel '%s' could not be found, but expansion exists. ", name);
-strm.Printf("Breakpoint placed on expanded kernel. Have you compiled in debug mode?");
-strm.EOL();
-}
-else
-{
-error.SetErrorStringWithFormat("Could not locate symbols for loaded kernel '%s'.", name);
-return;
-}
-}
-
-addr_t bp_addr = kernel_sym->GetLoadAddress(&GetProcess()->GetTarget());
-if (bp_addr == LLDB_INVALID_ADDRESS)
-{
-error.SetErrorStringWithFormat("Could not locate load address for symbols of k
[Lldb-commits] [lldb] r246843 - Move GetOptInc to the common namespace
Author: labath
Date: Fri Sep 4 04:06:15 2015
New Revision: 246843
URL: http://llvm.org/viewvc/llvm-project?rev=246843&view=rev
Log:
Move GetOptInc to the common namespace
Summary:
GetOptInc provides getopt(), getopt_long() and getopt_long_only().
Windows (for defined(_MSC_VER)) doesn't ship with all of the getopt(3) family
members and needs all of them. NetBSD requires only getopt_long_only(3).
While there fix the code for clang diagnostics.
Author: Kamil Rytarowski
Reviewers: joerg
Subscribers: labath, zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D12582
Added:
lldb/trunk/include/lldb/Host/common/GetOptInc.h
- copied, changed from r246841,
lldb/trunk/include/lldb/Host/windows/getopt/GetOptInc.h
lldb/trunk/source/Host/common/GetOptInc.cpp
- copied, changed from r246841,
lldb/trunk/source/Host/windows/getopt/GetOptInc.cpp
Removed:
lldb/trunk/include/lldb/Host/windows/getopt/GetOptInc.h
lldb/trunk/source/Host/windows/getopt/GetOptInc.cpp
Modified:
lldb/trunk/include/lldb/Host/HostGetOpt.h
lldb/trunk/source/Host/CMakeLists.txt
lldb/trunk/tools/lldb-mi/CMakeLists.txt
Modified: lldb/trunk/include/lldb/Host/HostGetOpt.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Host/HostGetOpt.h?rev=246843&r1=246842&r2=246843&view=diff
==
--- lldb/trunk/include/lldb/Host/HostGetOpt.h (original)
+++ lldb/trunk/include/lldb/Host/HostGetOpt.h Fri Sep 4 04:06:15 2015
@@ -8,7 +8,7 @@
//===--===//
#pragma once
-#ifndef _MSC_VER
+#if !defined(_MSC_VER) && !defined(__NetBSD__)
#ifdef _WIN32
#define _BSD_SOURCE // Required so that getopt.h defines optreset
@@ -19,6 +19,6 @@
#else
-#include
+#include
#endif
Copied: lldb/trunk/include/lldb/Host/common/GetOptInc.h (from r246841,
lldb/trunk/include/lldb/Host/windows/getopt/GetOptInc.h)
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Host/common/GetOptInc.h?p2=lldb/trunk/include/lldb/Host/common/GetOptInc.h&p1=lldb/trunk/include/lldb/Host/windows/getopt/GetOptInc.h&r1=246841&r2=246843&rev=246843&view=diff
==
--- lldb/trunk/include/lldb/Host/windows/getopt/GetOptInc.h (original)
+++ lldb/trunk/include/lldb/Host/common/GetOptInc.h Fri Sep 4 04:06:15 2015
@@ -2,6 +2,15 @@
#include "lldb/lldb-defines.h"
+#if defined(_MSC_VER)
+#define REPLACE_GETOPT
+#define REPLACE_GETOPT_LONG
+#endif
+#if defined(_MSC_VER) || defined(__NetBSD__)
+#define REPLACE_GETOPT_LONG_ONLY
+#endif
+
+#if defined(REPLACE_GETOPT)
// from getopt.h
#define no_argument 0
#define required_argument 1
@@ -28,7 +37,12 @@ extern intoptopt;
// defined in unistd.h
extern intoptreset;
+#else
+# include
+# include
+#endif
+#if defined(REPLACE_GETOPT_LONG)
int getopt_long
(
int argc,
@@ -37,7 +51,9 @@ int getopt_long
const struct option *longopts,
int *longindex
);
+#endif
+#if defined(REPLACE_GETOPT_LONG_ONLY)
int getopt_long_only
(
int argc,
@@ -46,3 +62,4 @@ int getopt_long_only
const struct option *longopts,
int *longindex
);
+#endif
Removed: lldb/trunk/include/lldb/Host/windows/getopt/GetOptInc.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Host/windows/getopt/GetOptInc.h?rev=246842&view=auto
==
--- lldb/trunk/include/lldb/Host/windows/getopt/GetOptInc.h (original)
+++ lldb/trunk/include/lldb/Host/windows/getopt/GetOptInc.h (removed)
@@ -1,48 +0,0 @@
-#pragma once
-
-#include "lldb/lldb-defines.h"
-
-// from getopt.h
-#define no_argument 0
-#define required_argument 1
-#define optional_argument 2
-
-// option structure
-struct option
-{
-const char *name;
-// has_arg can't be an enum because some compilers complain about
-// type mismatches in all the code that assumes it is an int.
-int has_arg;
-int *flag;
-int val;
-};
-
-int getopt( int argc, char * const argv[], const char *optstring );
-
-// from getopt.h
-extern char * optarg;
-extern intoptind;
-extern intopterr;
-extern intoptopt;
-
-// defined in unistd.h
-extern intoptreset;
-
-int getopt_long
-(
-int argc,
-char * const *argv,
-const char *optstring,
-const struct option *longopts,
-int *longindex
-);
-
-int getopt_long_only
-(
-int argc,
-char * const *argv,
-const char *optstring,
-const struct option *longopts,
-int *longindex
-);
Modified: lldb/trunk/source/Host/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Host/CMakeLists.txt?rev=246843&r1=246842&r2=246843&view=diff
==
--- lldb/trunk/source/Host/CMakeLists.txt (original)
+++ lldb/trunk/source/Host/CMakeList
Re: [Lldb-commits] [Diffusion] rL246639: Fix tab completion for command arguments containing spaces
Sorry for the breakage. It should be fixed by r246791 On Fri, Sep 4, 2015 at 1:34 AM Dawn Perchik wrote: > dawn added a subscriber: dawn. > dawn added a comment. > > We're seeing 2 new failures on OSX since this commit: > > > Failure-TestCompletion.CommandLineCompletionTestCase.test_symbol_name_dsym-x86_64-clang.log > > Failure-TestCompletion.CommandLineCompletionTestCase.test_symbol_name_dwarf-x86_64-clang.log > > Can you please have a look? Ok to XFAIL them? > > > Users: > tberghammer (Author) > > http://reviews.llvm.org/rL246639 > > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [Diffusion] rL246639: Fix tab completion for command arguments containing spaces
tberghammer added a subscriber: tberghammer. tberghammer added a comment. Sorry for the breakage. It should be fixed by r246791 Users: tberghammer (Author) http://reviews.llvm.org/rL246639 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12582: Move GetOptInc to the common namespace
This revision was automatically updated to reflect the committed changes.
Closed by commit rL246843: Move GetOptInc to the common namespace (authored by
labath).
Changed prior to commit:
http://reviews.llvm.org/D12582?vs=33944&id=34020#toc
Repository:
rL LLVM
http://reviews.llvm.org/D12582
Files:
lldb/trunk/include/lldb/Host/HostGetOpt.h
lldb/trunk/include/lldb/Host/common/GetOptInc.h
lldb/trunk/include/lldb/Host/windows/getopt/GetOptInc.h
lldb/trunk/source/Host/CMakeLists.txt
lldb/trunk/source/Host/common/GetOptInc.cpp
lldb/trunk/source/Host/windows/getopt/GetOptInc.cpp
lldb/trunk/tools/lldb-mi/CMakeLists.txt
Index: lldb/trunk/tools/lldb-mi/CMakeLists.txt
===
--- lldb/trunk/tools/lldb-mi/CMakeLists.txt
+++ lldb/trunk/tools/lldb-mi/CMakeLists.txt
@@ -81,7 +81,7 @@
if ( CMAKE_SYSTEM_NAME MATCHES "Windows" )
add_definitions( -DIMPORT_LIBLLDB )
list(APPEND LLDB_MI_SOURCES
-${LLDB_SOURCE_ROOT}/Host/windows/getopt/GetOptInc.cpp
+${LLDB_SOURCE_ROOT}/Host/common/GetOptInc.cpp
)
endif ()
Index: lldb/trunk/source/Host/CMakeLists.txt
===
--- lldb/trunk/source/Host/CMakeLists.txt
+++ lldb/trunk/source/Host/CMakeLists.txt
@@ -9,6 +9,7 @@
common/FileCache.cpp
common/FileSpec.cpp
common/FileSystem.cpp
+ common/GetOptInc.cpp
common/Host.cpp
common/HostInfoBase.cpp
common/HostNativeThreadBase.cpp
@@ -67,7 +68,6 @@
windows/ProcessRunLock.cpp
windows/ThisThread.cpp
windows/Windows.cpp
-windows/getopt/GetOptInc.cpp
)
else()
add_host_subdirectory(posix
Index: lldb/trunk/source/Host/windows/getopt/GetOptInc.cpp
===
--- lldb/trunk/source/Host/windows/getopt/GetOptInc.cpp
+++ lldb/trunk/source/Host/windows/getopt/GetOptInc.cpp
@@ -1,470 +0,0 @@
-#include "lldb/Host/windows/getopt/GetOptInc.h"
-
-// getopt.cpp
-#include
-#include
-#include
-
-#if defined(__clang__) && defined(_MSC_VER)
-#pragma clang diagnostic push
-#pragma clang diagnostic ignored "-Wwritable-strings"
-#endif
-
-int opterr = 1; /* if error message should be printed */
-int optind = 1; /* index into parent argv vector */
-int optopt = '?'; /* character checked for validity */
-int optreset; /* reset getopt */
-char *optarg; /* argument associated with option */
-
-#define PRINT_ERROR ((opterr) && (*options != ':'))
-
-#define FLAG_PERMUTE0x01/* permute non-options to the end of argv */
-#define FLAG_ALLARGS0x02/* treat non-options as args to option "-1" */
-#define FLAG_LONGONLY 0x04/* operate as getopt_long_only */
-
-/* return values */
-#define BADCH (int)'?'
-#define BADARG ((*options == ':') ? (int)':' : (int)'?')
-#define INORDER (int)1
-
-#define EMSG""
-
-static int getopt_internal(int, char * const *, const char *,
-const struct option *, int *, int);
-static int parse_long_options(char * const *, const char *,
-const struct option *, int *, int);
-static int gcd(int, int);
-static void permute_args(int, int, int, char * const *);
-
-static char *place = EMSG; /* option letter processing */
-
-/* XXX: set optreset to 1 rather than these two */
-static int nonopt_start = -1; /* first non option argument (for permute) */
-static int nonopt_end = -1; /* first option after non options (for permute) */
-
-/*
-* Compute the greatest common divisor of a and b.
-*/
-static int
-gcd(int a, int b)
-{
-int c;
-
-c = a % b;
-while (c != 0) {
-a = b;
-b = c;
-c = a % b;
-}
-
-return (b);
-}
-
-static void pass() {}
-#define warnx(a, ...) pass();
-
-/*
-* Exchange the block from nonopt_start to nonopt_end with the block
-* from nonopt_end to opt_end (keeping the same order of arguments
-* in each block).
-*/
-static void
-permute_args(int panonopt_start, int panonopt_end, int opt_end,
-char * const *nargv)
-{
-int cstart, cyclelen, i, j, ncycle, nnonopts, nopts, pos;
-char *swap;
-
-/*
-* compute lengths of blocks and number and size of cycles
-*/
-nnonopts = panonopt_end - panonopt_start;
-nopts = opt_end - panonopt_end;
-ncycle = gcd(nnonopts, nopts);
-cyclelen = (opt_end - panonopt_start) / ncycle;
-
-for (i = 0; i < ncycle; i++) {
-cstart = panonopt_end + i;
-pos = cstart;
-for (j = 0; j < cyclelen; j++) {
-if (pos >= panonopt_end)
-pos -= nnonopts;
-else
-pos += nopts;
-swap = nargv[pos];
-/* LINTED const cast */
-((char **)nargv)[pos] = nargv[cstart];
-/* LINTED const cast */
-((char **)nargv)[cstart] = swap;
-}
-}
-}
-
-/*
-* parse_long_options --
-* Parse long options in argc/argv argument vector.
-* Returns -1 if short_too is set and the option does not match long_op
Re: [Lldb-commits] [PATCH] D12601: Fix TestLoadUnload.test_load_unload for android API > 21
tberghammer added inline comments. Comment at: source/Core/Module.cpp:1712 @@ -1712,1 +1711,3 @@ +if (!FileSpec::Equal (file_spec, m_file, (bool)file_spec.GetDirectory()) && +!FileSpec::Equal (file_spec, m_platform_file, (bool)file_spec.GetDirectory())) return false; ovyalov wrote: > It might expose some tricky problems when host and target have the same > library with the same path but different content.. - please make sure that > there is no regressions. I run the test suit and seen no regression. If we have a library with the same path on the host and on the target and we don't have UUID then we are already having issues differentiating between them. In the case you described we treat them as matching modules even before my change. Comment at: source/Target/Platform.cpp:278 @@ +277,3 @@ + if (error.Success() && module_sp) + module_sp->SetPlatformFileSpec(spec.GetFileSpec()); + return error; ovyalov wrote: > What do you think about putting > module_sp->SetPlatformFileSpec(spec.GetFileSpec()) into > ModuleList::GetSharedModule ? I would like to limit the scope of this change to the case when remote debugging is used. It can be confusing if we set platform file spec even when no remote platform is involved http://reviews.llvm.org/D12601 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r246845 - Add a repro case for bug llvm.org/pr24702
Author: labath
Date: Fri Sep 4 05:21:15 2015
New Revision: 246845
URL: http://llvm.org/viewvc/llvm-project?rev=246845&view=rev
Log:
Add a repro case for bug llvm.org/pr24702
Added:
lldb/trunk/test/functionalities/jitloader_gdb/
lldb/trunk/test/functionalities/jitloader_gdb/Makefile
lldb/trunk/test/functionalities/jitloader_gdb/TestJITLoaderGDB.py
lldb/trunk/test/functionalities/jitloader_gdb/main.c
Added: lldb/trunk/test/functionalities/jitloader_gdb/Makefile
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/test/functionalities/jitloader_gdb/Makefile?rev=246845&view=auto
==
--- lldb/trunk/test/functionalities/jitloader_gdb/Makefile (added)
+++ lldb/trunk/test/functionalities/jitloader_gdb/Makefile Fri Sep 4 05:21:15
2015
@@ -0,0 +1,5 @@
+LEVEL = ../../make
+
+C_SOURCES := main.c
+
+include $(LEVEL)/Makefile.rules
Added: lldb/trunk/test/functionalities/jitloader_gdb/TestJITLoaderGDB.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/test/functionalities/jitloader_gdb/TestJITLoaderGDB.py?rev=246845&view=auto
==
--- lldb/trunk/test/functionalities/jitloader_gdb/TestJITLoaderGDB.py (added)
+++ lldb/trunk/test/functionalities/jitloader_gdb/TestJITLoaderGDB.py Fri Sep
4 05:21:15 2015
@@ -0,0 +1,50 @@
+"""Test for the JITLoaderGDB interface"""
+
+import os
+import unittest2
+import lldb
+from lldbtest import *
+import lldbutil
+import re
+
+
+class JITLoaderGDBTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+@skipTestIfFn(lambda x: True, "llvm.org/pr24702", "Skipped because the
test crashes the test runner")
+@unittest2.expectedFailure("llvm.org/pr24702")
+@dsym_test
+def test_bogus_values_with_dsym(self):
+self.buildDsym()
+self.bogus_values_test()
+
+@skipTestIfFn(lambda x: True, "llvm.org/pr24702", "Skipped because the
test crashes the test runner")
+@unittest2.expectedFailure("llvm.org/pr24702")
+@dwarf_test
+def test_bogus_values_with_dwarf(self):
+self.buildDwarf()
+self.bogus_values_test()
+
+def bogus_values_test(self):
+"""Test that we handle inferior misusing the GDB JIT interface"""
+exe = os.path.join(os.getcwd(), "a.out")
+
+# Create a target by the debugger.
+target = self.dbg.CreateTarget(exe)
+self.assertTrue(target, VALID_TARGET)
+
+# launch the process, do not stop at entry point.
+process = target.LaunchSimple(None, None,
self.get_process_working_directory())
+self.assertTrue(process, PROCESS_IS_VALID)
+
+# The inferior will now pass bogus values over the interface. Make
sure we don't crash.
+
+self.assertEqual(process.GetState(), lldb.eStateExited)
+self.assertEqual(process.GetExitStatus(), 0)
+
+if __name__ == '__main__':
+import atexit
+lldb.SBDebugger.Initialize()
+atexit.register(lambda: lldb.SBDebugger.Terminate())
+unittest2.main()
Added: lldb/trunk/test/functionalities/jitloader_gdb/main.c
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/test/functionalities/jitloader_gdb/main.c?rev=246845&view=auto
==
--- lldb/trunk/test/functionalities/jitloader_gdb/main.c (added)
+++ lldb/trunk/test/functionalities/jitloader_gdb/main.c Fri Sep 4 05:21:15
2015
@@ -0,0 +1,44 @@
+#include
+
+// GDB JIT interface
+enum JITAction { JIT_NOACTION, JIT_REGISTER_FN, JIT_UNREGISTER_FN };
+
+struct JITCodeEntry
+{
+struct JITCodeEntry* next;
+struct JITCodeEntry* prev;
+const char *symfile_addr;
+uint64_t symfile_size;
+};
+
+struct JITDescriptor
+{
+uint32_t version;
+uint32_t action_flag;
+struct JITCodeEntry* relevant_entry;
+struct JITCodeEntry* first_entry;
+};
+
+struct JITDescriptor __jit_debug_descriptor = { 1, JIT_NOACTION, 0, 0 };
+
+void __jit_debug_register_code()
+{
+}
+// end GDB JIT interface
+
+struct JITCodeEntry entry;
+
+int main()
+{
+// Create a code entry with a bogus size
+entry.next = entry.prev = 0;
+entry.symfile_addr = (char *)&entry;
+entry.symfile_size = (uint64_t)47<<32;
+
+__jit_debug_descriptor.relevant_entry = __jit_debug_descriptor.first_entry
= &entry;
+__jit_debug_descriptor.action_flag = JIT_REGISTER_FN;
+
+__jit_debug_register_code();
+
+return 0;
+}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r246847 - Fix multiple problems in -break-condition command.
Author: abidh
Date: Fri Sep 4 06:26:53 2015
New Revision: 246847
URL: http://llvm.org/viewvc/llvm-project?rev=246847&view=rev
Log:
Fix multiple problems in -break-condition command.
1. To handle the expression with spaces, this command uses 2 arguments. For a
case
like -break-condition 1 i == 5, the first will pick the 'i' and second will
pick the '== 5'. But the second argument was made mandatory which failed in
cases when there was no space in the expression like i==5.
2. The function GetRestOfExpressionNotSurroundedInQuotes has 2 locals with the
same names. It resulted in one hiding the other and this function always
returned empty string.
No regression on Linux. Committed as obvious.
Modified:
lldb/trunk/tools/lldb-mi/MICmdCmdBreak.cpp
Modified: lldb/trunk/tools/lldb-mi/MICmdCmdBreak.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/lldb-mi/MICmdCmdBreak.cpp?rev=246847&r1=246846&r2=246847&view=diff
==
--- lldb/trunk/tools/lldb-mi/MICmdCmdBreak.cpp (original)
+++ lldb/trunk/tools/lldb-mi/MICmdCmdBreak.cpp Fri Sep 4 06:26:53 2015
@@ -937,7 +937,7 @@ CMICmdCmdBreakCondition::ParseArgs()
*(new CMICmdArgValOptionLong(m_constStrArgNamedThreadGrp, false,
false, CMICmdArgValListBase::eArgValType_ThreadGrp, 1)));
m_setCmdArgs.Add(*(new CMICmdArgValNumber(m_constStrArgNamedNumber, true,
true)));
m_setCmdArgs.Add(*(new CMICmdArgValString(m_constStrArgNamedExpr, true,
true, true, true)));
-m_setCmdArgs.Add(*(new CMICmdArgValListOfN(m_constStrArgNamedExprNoQuotes,
true, false,
+m_setCmdArgs.Add(*(new CMICmdArgValListOfN(m_constStrArgNamedExprNoQuotes,
false, false,
CMICmdArgValListBase::eArgValType_StringQuotedNumber)));
return ParseValidateCmdOptions();
}
@@ -1042,7 +1042,6 @@ CMICmdCmdBreakCondition::GetRestOfExpres
CMICmdArgValListOfN *pArgExprNoQuotes =
CMICmdBase::GetOption(m_constStrArgNamedExprNoQuotes);
if (pArgExprNoQuotes != nullptr)
{
-CMIUtilString strExpression;
const CMICmdArgValListBase::VecArgObjPtr_t
&rVecExprParts(pArgExprNoQuotes->GetExpectedOptions());
if (!rVecExprParts.empty())
{
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12079: [MIPS] microMIPS breakpoints, disassembly and compressed addresses
jaydeep added inline comments.
Comment at: source/Target/RegisterContext.cpp:106-116
@@ -105,3 +105,13 @@
uint32_t reg = ConvertRegisterKindToRegisterNumber (eRegisterKindGeneric,
LLDB_REGNUM_GENERIC_PC);
-return ReadRegisterAsUnsigned (reg, fail_value);
+uint64_t pc = ReadRegisterAsUnsigned (reg, fail_value);
+
+if (pc != fail_value)
+{
+TargetSP target_sp = m_thread.CalculateTarget();
+Target *target = target_sp.get();
+Address addr (pc);
+pc = addr.GetOpcodeLoadAddress (target);
+}
+
+return pc;
}
clayborg wrote:
> Bit #0 should be stripped from the PC before it is figured out and the frame
> might need to track the address class, so this change shouldn't be needed. We
> don't want extra bits floating around in our code that we have to strip
> everywhere. This should be done as the stack frames are being created. The
> frame will need to keep track of the address class in case the address
> doesn't map back to a shared library (JITed code might not have a module
> describing the code). So this code should be removed and the backtracer will
> need to sanitize the addresses as the PC values are unwound.
The breakpoint is set on OpcodeAddress (bit #0 clear), but target returns
CallableAddress (bit #0 set) when breakpoint is hit.
Set using:
StoppointLocation (loc_id, addr.GetOpcodeLoadAddress(&owner.GetTarget()),
hardware)
Find using:
addr_t pc = thread_sp->GetRegisterContext()->GetPC() + m_breakpoint_pc_offset;
lldb::BreakpointSiteSP bp_site_sp =
thread_sp->GetProcess()->GetBreakpointSiteList().FindByAddress(pc);
We either need to clear bit #0 from the PC we get or need to set the breakpoint
on CallableAddress (which would need LineTable in CallableAddress form).
Repository:
rL LLVM
http://reviews.llvm.org/D12079
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r246852 - Fix TestLoadUnload.test_load_unload for android API > 21
Author: tberghammer
Date: Fri Sep 4 07:42:41 2015
New Revision: 246852
URL: http://llvm.org/viewvc/llvm-project?rev=246852&view=rev
Log:
Fix TestLoadUnload.test_load_unload for android API > 21
* Change Module::MatchesModuleSpec to return true in case the file spec
in the specified module spec matches with the platform file spec, but
not with the local file spec
* Change the module_resolver used when resolving a remote shared module
to always set the platform file spec to the file spec requested
Differential revision: http://reviews.llvm.org/D12601
Modified:
lldb/trunk/source/Core/Module.cpp
lldb/trunk/source/Target/Platform.cpp
Modified: lldb/trunk/source/Core/Module.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Module.cpp?rev=246852&r1=246851&r2=246852&view=diff
==
--- lldb/trunk/source/Core/Module.cpp (original)
+++ lldb/trunk/source/Core/Module.cpp Fri Sep 4 07:42:41 2015
@@ -1708,7 +1708,8 @@ Module::MatchesModuleSpec (const ModuleS
const FileSpec &file_spec = module_ref.GetFileSpec();
if (file_spec)
{
-if (!FileSpec::Equal (file_spec, m_file,
(bool)file_spec.GetDirectory()))
+if (!FileSpec::Equal (file_spec, m_file,
(bool)file_spec.GetDirectory()) &&
+!FileSpec::Equal (file_spec, m_platform_file,
(bool)file_spec.GetDirectory()))
return false;
}
Modified: lldb/trunk/source/Target/Platform.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/Platform.cpp?rev=246852&r1=246851&r2=246852&view=diff
==
--- lldb/trunk/source/Target/Platform.cpp (original)
+++ lldb/trunk/source/Target/Platform.cpp Fri Sep 4 07:42:41 2015
@@ -272,8 +272,11 @@ Platform::GetSharedModule (const ModuleS
module_sp,
[&](const ModuleSpec &spec)
{
- return ModuleList::GetSharedModule (
+ Error error =
ModuleList::GetSharedModule (
spec, module_sp,
module_search_paths_ptr, old_module_sp_ptr, did_create_ptr, false);
+ if (error.Success() && module_sp)
+
module_sp->SetPlatformFileSpec(spec.GetFileSpec());
+ return error;
},
did_create_ptr);
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12601: Fix TestLoadUnload.test_load_unload for android API > 21
This revision was automatically updated to reflect the committed changes.
Closed by commit rL246852: Fix TestLoadUnload.test_load_unload for android API
> 21 (authored by tberghammer).
Changed prior to commit:
http://reviews.llvm.org/D12601?vs=33949&id=34025#toc
Repository:
rL LLVM
http://reviews.llvm.org/D12601
Files:
lldb/trunk/source/Core/Module.cpp
lldb/trunk/source/Target/Platform.cpp
Index: lldb/trunk/source/Core/Module.cpp
===
--- lldb/trunk/source/Core/Module.cpp
+++ lldb/trunk/source/Core/Module.cpp
@@ -1708,7 +1708,8 @@
const FileSpec &file_spec = module_ref.GetFileSpec();
if (file_spec)
{
-if (!FileSpec::Equal (file_spec, m_file,
(bool)file_spec.GetDirectory()))
+if (!FileSpec::Equal (file_spec, m_file,
(bool)file_spec.GetDirectory()) &&
+!FileSpec::Equal (file_spec, m_platform_file,
(bool)file_spec.GetDirectory()))
return false;
}
Index: lldb/trunk/source/Target/Platform.cpp
===
--- lldb/trunk/source/Target/Platform.cpp
+++ lldb/trunk/source/Target/Platform.cpp
@@ -272,8 +272,11 @@
module_sp,
[&](const ModuleSpec &spec)
{
- return ModuleList::GetSharedModule (
+ Error error =
ModuleList::GetSharedModule (
spec, module_sp,
module_search_paths_ptr, old_module_sp_ptr, did_create_ptr, false);
+ if (error.Success() && module_sp)
+
module_sp->SetPlatformFileSpec(spec.GetFileSpec());
+ return error;
},
did_create_ptr);
}
Index: lldb/trunk/source/Core/Module.cpp
===
--- lldb/trunk/source/Core/Module.cpp
+++ lldb/trunk/source/Core/Module.cpp
@@ -1708,7 +1708,8 @@
const FileSpec &file_spec = module_ref.GetFileSpec();
if (file_spec)
{
-if (!FileSpec::Equal (file_spec, m_file, (bool)file_spec.GetDirectory()))
+if (!FileSpec::Equal (file_spec, m_file, (bool)file_spec.GetDirectory()) &&
+!FileSpec::Equal (file_spec, m_platform_file, (bool)file_spec.GetDirectory()))
return false;
}
Index: lldb/trunk/source/Target/Platform.cpp
===
--- lldb/trunk/source/Target/Platform.cpp
+++ lldb/trunk/source/Target/Platform.cpp
@@ -272,8 +272,11 @@
module_sp,
[&](const ModuleSpec &spec)
{
- return ModuleList::GetSharedModule (
+ Error error = ModuleList::GetSharedModule (
spec, module_sp, module_search_paths_ptr, old_module_sp_ptr, did_create_ptr, false);
+ if (error.Success() && module_sp)
+ module_sp->SetPlatformFileSpec(spec.GetFileSpec());
+ return error;
},
did_create_ptr);
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D12634: Fix -data-evaluate-expression for array.
abidh created this revision.
abidh added a reviewer: ki.stfu.
abidh added a subscriber: lldb-commits.
For an array declared like "blk[2][3]", this command was showing:
-data-evaluate-expression blk
^done,value="{[0] = [3], [1] = [3]}"
After this fix, it shows:
-data-evaluate-expression blk
^done,value="{[0] = {[0] = 1, [1] = 2, [2] = 3}, [1] = {[0] = 4, [1] = 5, [2] =
6}}"
The code to do the right thing was already available and used by other commands.
So I have just used that and removed the half-baked previous implementation.
http://reviews.llvm.org/D12634
Files:
test/tools/lldb-mi/variable/TestMiVar.py
test/tools/lldb-mi/variable/main.cpp
tools/lldb-mi/MICmdCmdData.cpp
tools/lldb-mi/MICmdCmdData.h
Index: tools/lldb-mi/MICmdCmdData.h
===
--- tools/lldb-mi/MICmdCmdData.h
+++ tools/lldb-mi/MICmdCmdData.h
@@ -73,7 +73,6 @@
bool m_bEvaluatedExpression; // True = yes is expression evaluated, false = failed
CMIUtilString m_strValue;
CMICmnMIValueTuple m_miValueTuple;
-bool m_bCompositeVarType; // True = yes composite type, false = internal type
bool m_bFoundInvalidChar; // True = yes found unexpected character in the expression, false = all ok
char m_cExpressionInvalidChar;
const CMIUtilString m_constStrArgThread; // Not specified in MI spec but Eclipse gives this option. Not handled by command.
Index: tools/lldb-mi/MICmdCmdData.cpp
===
--- tools/lldb-mi/MICmdCmdData.cpp
+++ tools/lldb-mi/MICmdCmdData.cpp
@@ -54,7 +54,6 @@
: m_bExpressionValid(true)
, m_bEvaluatedExpression(true)
, m_strValue("??")
-, m_bCompositeVarType(false)
, m_bFoundInvalidChar(false)
, m_cExpressionInvalidChar(0x00)
, m_constStrArgThread("thread")
@@ -145,41 +144,7 @@
m_strValue = rExpression.Trim('\"');
return MIstatus::success;
}
-
-MIuint64 nNumber = 0;
-if (CMICmnLLDBProxySBValue::GetValueAsUnsigned(value, nNumber) == MIstatus::success)
-{
-const lldb::ValueType eValueType = value.GetValueType();
-MIunused(eValueType);
-m_strValue = utilValue.GetValue().Escape().AddSlashes();
-return MIstatus::success;
-}
-
-// Composite type i.e. struct
-m_bCompositeVarType = true;
-const MIuint nChild = value.GetNumChildren();
-for (MIuint i = 0; i < nChild; i++)
-{
-lldb::SBValue member = value.GetChildAtIndex(i);
-const bool bValid = member.IsValid();
-CMIUtilString strType(MIRSRC(IDS_WORD_UNKNOWNTYPE_BRKTS));
-if (bValid)
-{
-const CMIUtilString strValue(
-CMICmnLLDBDebugSessionInfoVarObj::GetValueStringFormatted(member, CMICmnLLDBDebugSessionInfoVarObj::eVarFormat_Natural));
-const char *pTypeName = member.GetName();
-if (pTypeName != nullptr)
-strType = pTypeName;
-
-// MI print "{variable = 1, variable2 = 3, variable3 = 5}"
-const bool bNoQuotes = true;
-const CMICmnMIValueConst miValueConst(strValue, bNoQuotes);
-const bool bUseSpaces = true;
-const CMICmnMIValueResult miValueResult(strType, miValueConst, bUseSpaces);
-m_miValueTuple.Add(miValueResult, bUseSpaces);
-}
-}
-
+m_strValue = utilValue.GetValue(true).Escape().AddSlashes();
return MIstatus::success;
}
@@ -199,15 +164,6 @@
{
if (m_bEvaluatedExpression)
{
-if (m_bCompositeVarType)
-{
-const CMICmnMIValueConst miValueConst(m_miValueTuple.GetString());
-const CMICmnMIValueResult miValueResult("value", miValueConst);
-const CMICmnMIResultRecord miRecordResult(m_cmdData.strMiCmdToken, CMICmnMIResultRecord::eResultClass_Done, miValueResult);
-m_miResultRecord = miRecordResult;
-return MIstatus::success;
-}
-
if (m_bFoundInvalidChar)
{
const CMICmnMIValueConst miValueConst(
Index: test/tools/lldb-mi/variable/main.cpp
===
--- test/tools/lldb-mi/variable/main.cpp
+++ test/tools/lldb-mi/variable/main.cpp
@@ -96,11 +96,18 @@
int g_MyVar = 3;
static int s_MyVar = 4;
+int g_blk[2][3];
int
main(int argc, char const *argv[])
{
int a = 10, b = 20;
+g_blk[0][0] = 1;
+g_blk[0][1] = 2;
+g_blk[0][2] = 3;
+g_blk[1][0] = 4;
+g_blk[1][1] = 5;
+g_blk[1][2] = 6;
s_MyVar = a + b;
var_update_test();
var_list_children_test();
Index: test/tools/lldb-mi/variable/TestMiVar.py
===
--- test/tools/lldb-mi/variable/TestMiVar.py
+++ test/tools/lldb-mi/variable/TestMiVar.py
@@ -36,6 +36,10 @@
self.expect("\^error,msg=\"error: error: use of undeclared identif
Re: [Lldb-commits] [PATCH] D5806: Compiler args patch resubmission
tfiala resigned from this revision. tfiala removed a reviewer: tfiala. tfiala added a comment. Stale and not happening AFAICT. http://reviews.llvm.org/D5806 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D12636: Fix the handling of FPR offsets in Linux arm/aarch64 register contexts
tberghammer created this revision.
tberghammer added reviewers: labath, chaoren, omjavaid.
tberghammer added a subscriber: lldb-commits.
Herald added subscribers: danalbert, tberghammer, rengolin, aemerson.
Fix the handling of FPR offsets in Linux arm/aarch64 register contexts
This should fix the expression evaluation on the Android-aarch64 build bot, but
I haven't managed to reproduce the issue locally
http://reviews.llvm.org/D12636
Files:
source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp
source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.h
source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
source/Plugins/Process/Utility/RegisterContextLinux_arm64.cpp
Index: source/Plugins/Process/Utility/RegisterContextLinux_arm64.cpp
===
--- source/Plugins/Process/Utility/RegisterContextLinux_arm64.cpp
+++ source/Plugins/Process/Utility/RegisterContextLinux_arm64.cpp
@@ -21,7 +21,7 @@
#define GPR_OFFSET_NAME(reg) (LLVM_EXTENSION offsetof (RegisterContextLinux_arm64::GPR, reg))
#define FPU_OFFSET(idx) ((idx) * 16 + sizeof (RegisterContextLinux_arm64::GPR))
-#define FPU_OFFSET_NAME(reg) (LLVM_EXTENSION offsetof (RegisterContextLinux_arm64::FPU, reg))
+#define FPU_OFFSET_NAME(reg) (LLVM_EXTENSION offsetof (RegisterContextLinux_arm64::FPU, reg) + sizeof (RegisterContextLinux_arm64::GPR))
#define EXC_OFFSET_NAME(reg) (LLVM_EXTENSION offsetof (RegisterContextLinux_arm64::EXC, reg) + sizeof (RegisterContextLinux_arm64::GPR) + sizeof (RegisterContextLinux_arm64::FPU))
#define DBG_OFFSET_NAME(reg) (LLVM_EXTENSION offsetof (RegisterContextLinux_arm64::DBG, reg) + sizeof (RegisterContextLinux_arm64::GPR) + sizeof (RegisterContextLinux_arm64::FPU) + sizeof (RegisterContextLinux_arm64::EXC))
Index: source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
===
--- source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
+++ source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
@@ -183,6 +183,9 @@
Error
WriteHardwareDebugRegs(int hwbType);
+
+uint32_t
+CalculateFprOffset(const RegisterInfo* reg_info) const;
};
} // namespace process_linux
Index: source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
===
--- source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
+++ source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
@@ -249,8 +249,9 @@
}
// Get pointer to m_fpr variable and set the data from it.
-assert (reg_info->byte_offset < sizeof m_fpr);
-uint8_t *src = (uint8_t *)&m_fpr + reg_info->byte_offset;
+uint32_t fpr_offset = CalculateFprOffset(reg_info);
+assert (fpr_offset < sizeof m_fpr);
+uint8_t *src = (uint8_t *)&m_fpr + fpr_offset;
reg_value.SetFromMemoryData(reg_info, src, reg_info->byte_size, eByteOrderLittle, error);
return error;
@@ -272,8 +273,9 @@
if (IsFPR(reg_index))
{
// Get pointer to m_fpr variable and set the data to it.
-assert (reg_info->byte_offset < sizeof(m_fpr));
-uint8_t *dst = (uint8_t *)&m_fpr + reg_info->byte_offset;
+uint32_t fpr_offset = CalculateFprOffset(reg_info);
+assert (fpr_offset < sizeof m_fpr);
+uint8_t *dst = (uint8_t *)&m_fpr + fpr_offset;
switch (reg_info->byte_size)
{
case 2:
@@ -980,4 +982,10 @@
return NativeProcessLinux::PtraceWrapper(PTRACE_SETREGSET, m_thread.GetID(), ®set, &ioVec, buf_size);
}
+uint32_t
+NativeRegisterContextLinux_arm64::CalculateFprOffset(const RegisterInfo* reg_info) const
+{
+return reg_info->byte_offset - GetRegisterInfoAtIndex(m_reg_info.first_fpr)->byte_offset;
+}
+
#endif // defined (__arm64__) || defined (__aarch64__)
Index: source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.h
===
--- source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.h
+++ source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.h
@@ -161,6 +161,9 @@
Error
WriteHardwareDebugRegs(int hwbType, int hwb_index);
+
+uint32_t
+CalculateFprOffset(const RegisterInfo* reg_info) const;
};
} // namespace process_linux
Index: source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp
===
--- source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp
+++ source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp
@@ -229,8 +229,9 @@
}
// Get pointer to m_fpr variable and set the data from it.
-assert (reg_info->byte_offset < sizeof m_fpr);
-uint8_t *src = (uint8_t *)&m_fpr + reg_info->byte_offset;
+uint32_t fpr_offset = Calcula
Re: [Lldb-commits] [PATCH] D11102: Set the default language to use when evaluating to that of the frame's CU.
It isn't technically necessary, but on OS X it is very common for people to want to examine global app state from wherever and that is always ObjC, so we'd tick off our users if we forced them to explicitly dial up ObjC in other contexts. For other platforms it would be fine to choose just C++. And if the user explicitly dials up C++ (by passing --language) it should be fine to not add ObjC. But if we're setting it automatically on OS X there's a pretty strong expectation that you can just run an expression and ObjC types will be available. Jim > On Sep 3, 2015, at 7:08 PM, Dawn Perchik wrote: > > dawn added a comment. > > In http://reviews.llvm.org/D11102#234730, @spyffe wrote: > >> I want to follow up and make non-Apple platforms not force ObjC (it doesn't >> matter for making the expression parser work). > > > Hi Sean, > > I have one question about this that still bugs me... I understand that C++ > is needed in C and ObjC because of implementation details of expression > evaluation, but why is ObjC needed for C++? > > It will be awesome if/when you can follow up on this and remove this > requirement. Let me know when that's done and I'll remove the workarounds > that force ObjC and give it a try. > > Thanks! > > > Repository: > rL LLVM > > http://reviews.llvm.org/D11102 > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D11102: Set the default language to use when evaluating to that of the frame's CU.
jingham added a subscriber: jingham. jingham added a comment. It isn't technically necessary, but on OS X it is very common for people to want to examine global app state from wherever and that is always ObjC, so we'd tick off our users if we forced them to explicitly dial up ObjC in other contexts. For other platforms it would be fine to choose just C++. And if the user explicitly dials up C++ (by passing --language) it should be fine to not add ObjC. But if we're setting it automatically on OS X there's a pretty strong expectation that you can just run an expression and ObjC types will be available. Jim Repository: rL LLVM http://reviews.llvm.org/D11102 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12556: Use eAddressClassCode for address lookup for opcodes
tberghammer updated this revision to Diff 34038.
tberghammer added a comment.
Updated the change based on the comments.
I don't fully agree with restricting the user from setting breakpoint in
non-code locations because if LLDB classified a section incorrectly (e.g.
haven't found the SO file for it) the user might want to still set a breakpoint
there. In general I would like to make it possible to set a breakpoint at any
address (even on un-aligned ones) but warn the user that it might be incorrect.
http://reviews.llvm.org/D12556
Files:
include/lldb/Core/Address.h
source/API/SBFrame.cpp
source/Core/Address.cpp
source/Target/StackFrame.cpp
source/Target/StackFrameList.cpp
Index: source/Target/StackFrameList.cpp
===
--- source/Target/StackFrameList.cpp
+++ source/Target/StackFrameList.cpp
@@ -362,8 +362,8 @@
// adjustment it will point to an other section. In that case resolve the
// address again to the correct section plus offset form.
TargetSP target = m_thread.CalculateTarget();
-addr_t load_addr = curr_frame_address.GetOpcodeLoadAddress(target.get());
-curr_frame_address.SetOpcodeLoadAddress(load_addr - 1, target.get());
+addr_t load_addr = curr_frame_address.GetOpcodeLoadAddress(target.get(), eAddressClassCode);
+curr_frame_address.SetOpcodeLoadAddress(load_addr - 1, target.get(), eAddressClassCode);
}
else
{
Index: source/Target/StackFrame.cpp
===
--- source/Target/StackFrame.cpp
+++ source/Target/StackFrame.cpp
@@ -259,7 +259,7 @@
TargetSP target_sp (thread_sp->CalculateTarget());
if (target_sp)
{
-if (m_frame_code_addr.SetOpcodeLoadAddress (m_frame_code_addr.GetOffset(), target_sp.get()))
+if (m_frame_code_addr.SetOpcodeLoadAddress (m_frame_code_addr.GetOffset(), target_sp.get(), eAddressClassCode))
{
ModuleSP module_sp (m_frame_code_addr.GetModule());
if (module_sp)
Index: source/Core/Address.cpp
===
--- source/Core/Address.cpp
+++ source/Core/Address.cpp
@@ -367,21 +367,29 @@
}
addr_t
-Address::GetOpcodeLoadAddress (Target *target) const
+Address::GetOpcodeLoadAddress (Target *target, AddressClass addr_class) const
{
addr_t code_addr = GetLoadAddress (target);
if (code_addr != LLDB_INVALID_ADDRESS)
-code_addr = target->GetOpcodeLoadAddress (code_addr, GetAddressClass());
+{
+if (addr_class == eAddressClassInvalid)
+addr_class = GetAddressClass();
+code_addr = target->GetOpcodeLoadAddress (code_addr, addr_class);
+}
return code_addr;
}
bool
-Address::SetOpcodeLoadAddress (lldb::addr_t load_addr, Target *target)
+Address::SetOpcodeLoadAddress (lldb::addr_t load_addr, Target *target, AddressClass addr_class)
{
if (SetLoadAddress (load_addr, target))
{
if (target)
-m_offset = target->GetOpcodeLoadAddress (m_offset, GetAddressClass());
+{
+if (addr_class == eAddressClassInvalid)
+addr_class = GetAddressClass();
+m_offset = target->GetOpcodeLoadAddress (m_offset, addr_class);
+}
return true;
}
return false;
Index: source/API/SBFrame.cpp
===
--- source/API/SBFrame.cpp
+++ source/API/SBFrame.cpp
@@ -484,7 +484,7 @@
frame = exe_ctx.GetFramePtr();
if (frame)
{
-addr = frame->GetFrameCodeAddress().GetOpcodeLoadAddress (target);
+addr = frame->GetFrameCodeAddress().GetOpcodeLoadAddress (target, eAddressClassCode);
}
else
{
Index: include/lldb/Core/Address.h
===
--- include/lldb/Core/Address.h
+++ include/lldb/Core/Address.h
@@ -326,7 +326,8 @@
/// not loaded.
//--
lldb::addr_t
-GetOpcodeLoadAddress (Target *target) const;
+GetOpcodeLoadAddress (Target *target,
+ lldb::AddressClass addr_class = lldb::eAddressClassInvalid) const;
//--
/// Get the section relative offset value.
@@ -425,7 +426,9 @@
SetLoadAddress (lldb::addr_t load_addr, Target *target);
bool
-SetOpcodeLoadAddress (lldb::addr_t load_addr, Target *target);
+SetOpcodeLoadAddress (lldb::addr_t load_addr,
+ Target *target,
+
[Lldb-commits] [lldb] r246858 - Fix CMICmdArgValConsume to correctly handle "--".
Author: abidh
Date: Fri Sep 4 11:10:48 2015
New Revision: 246858
URL: http://llvm.org/viewvc/llvm-project?rev=246858&view=rev
Log:
Fix CMICmdArgValConsume to correctly handle "--".
CMICmdArgValConsume::Validate was not removing it from the input stream.
Modified:
lldb/trunk/tools/lldb-mi/MICmdArgValConsume.cpp
Modified: lldb/trunk/tools/lldb-mi/MICmdArgValConsume.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/lldb-mi/MICmdArgValConsume.cpp?rev=246858&r1=246857&r2=246858&view=diff
==
--- lldb/trunk/tools/lldb-mi/MICmdArgValConsume.cpp (original)
+++ lldb/trunk/tools/lldb-mi/MICmdArgValConsume.cpp Fri Sep 4 11:10:48 2015
@@ -72,12 +72,10 @@ CMICmdArgValConsume::Validate(CMICmdArgC
{
m_bFound = true;
m_bValid = true;
+if ( !vwArgContext.RemoveArg( rTxt ) )
+return MIstatus::failure;
return MIstatus::success;
}
-
-if ( !vwArgContext.RemoveArg( rTxt ) )
-return MIstatus::failure;
-
// Next
++it;
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12556: Use eAddressClassCode for address lookup for opcodes
jingham added a subscriber: jingham. jingham added a comment. If the user says "break set -a " I have no problem with our setting the breakpoint there even if we don't think it is a terribly good idea. But if lldb is converting any other specification to an address, it should always move past data in text. The failure modes if you aren't careful about this are really confusing: "Why was the first value in my enum whatever the trap instruction is on your platform..." etc... If allowing the former makes it hard to do the latter, the latter should have priority. Jim http://reviews.llvm.org/D12556 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12556: Use eAddressClassCode for address lookup for opcodes
tberghammer added a comment. I agree that we want to enable it only in very special cases when the user really know what he/she wants (probably pass in a --force flag). Anyway, it isn't implemented with this change and I don't expect it to be implemented in the near future. http://reviews.llvm.org/D12556 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12556: Use eAddressClassCode for address lookup for opcodes
If the user says "break set -a " I have no problem with our setting the breakpoint there even if we don't think it is a terribly good idea. But if lldb is converting any other specification to an address, it should always move past data in text. The failure modes if you aren't careful about this are really confusing: "Why was the first value in my enum whatever the trap instruction is on your platform..." etc... If allowing the former makes it hard to do the latter, the latter should have priority. Jim > On Sep 4, 2015, at 9:11 AM, Tamas Berghammer via lldb-commits > wrote: > > tberghammer updated this revision to Diff 34038. > tberghammer added a comment. > > Updated the change based on the comments. > > I don't fully agree with restricting the user from setting breakpoint in > non-code locations because if LLDB classified a section incorrectly (e.g. > haven't found the SO file for it) the user might want to still set a > breakpoint there. In general I would like to make it possible to set a > breakpoint at any address (even on un-aligned ones) but warn the user that it > might be incorrect. > > > http://reviews.llvm.org/D12556 > > Files: > include/lldb/Core/Address.h > source/API/SBFrame.cpp > source/Core/Address.cpp > source/Target/StackFrame.cpp > source/Target/StackFrameList.cpp > > ___ > lldb-commits mailing list > lldb-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r246859 - Use correct #ifdef check for ProcessWindowsLog::Terminate() call.
Author: abidh Date: Fri Sep 4 11:34:19 2015 New Revision: 246859 URL: http://llvm.org/viewvc/llvm-project?rev=246859&view=rev Log: Use correct #ifdef check for ProcessWindowsLog::Terminate() call. The call to ProcessWindowsLog::Initialize() is protected by #if defined(_MSC_VER). But the call to ProcessWindowsLog::Terminate() was using __WIN32__. This commit makes it use _MSC_VER too. Committing as it seems obvious change. Modified: lldb/trunk/source/Initialization/SystemInitializerCommon.cpp Modified: lldb/trunk/source/Initialization/SystemInitializerCommon.cpp URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Initialization/SystemInitializerCommon.cpp?rev=246859&r1=246858&r2=246859&view=diff == --- lldb/trunk/source/Initialization/SystemInitializerCommon.cpp (original) +++ lldb/trunk/source/Initialization/SystemInitializerCommon.cpp Fri Sep 4 11:34:19 2015 @@ -174,7 +174,7 @@ SystemInitializerCommon::Terminate() PlatformDarwinKernel::Terminate(); #endif -#if defined(__WIN32__) +#if defined(_MSC_VER) ProcessWindowsLog::Terminate(); #endif ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12636: Fix the handling of FPR offsets in Linux arm/aarch64 register contexts
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
I would rather see the register variables laid out in a way which makes the
offsets meaningful. I.e., instead of having m_fpr, m_gpr, ... we put something
like
struct Regs {
uint32_t gpr[...];
FPU fpu;
DREG hbr_regs;
...
};
Regs m_registers;
Then the byte offset field in Register Info structure will truly correspond to
the offset in this structure, and we can index it simply with:
assert(offset < sizeof m_register);
address = (char *)&m_registers + offset;
But if you want to keep this change small then it's ok for now.
http://reviews.llvm.org/D12636
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12556: Use eAddressClassCode for address lookup for opcodes
clayborg accepted this revision. clayborg added a comment. This revision is now accepted and ready to land. We really do need to restrict this for single stepping purposes. If the thread plans that single step and set breakpoints for stepping think they should place a breakpoint on 0x1004 if the example below: 0x1000: bx Non-tail call in a no return function 0x1004: [data-pool] Marked with $d mapping symbol You will change the data with the software breakpoint instruction and change the flow of your program incorrectly. I do agree we should have a "force" option to allow this to be done by the user, but we need to do due diligence to make sure we don't do this in LLDB code. Your updated changes look good though. http://reviews.llvm.org/D12556 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [Diffusion] rL246794: Roll dosep.py parallel test runner into dotest.py command line
dawn added a subscriber: lldb-commits. Users: tfiala (Author) http://reviews.llvm.org/rL246794 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12585: Add a TypeSystem for Go
clayborg accepted this revision. clayborg added a comment. This revision is now accepted and ready to land. Looks good. Comment at: include/lldb/Symbol/ClangASTContext.h:484 @@ -483,3 +483,3 @@ //-- - + ClangASTContext* remove this space diff http://reviews.llvm.org/D12585 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [Diffusion] rL246794: Roll dosep.py parallel test runner into dotest.py command line
dawn added a subscriber: dawn.
dawn raised a concern with this commit.
dawn added a comment.
I'm very unhappy with this change. Before I could count up all the test
failures using:
./dotest.py -v --executable $INSTALLDIR/bin/lldb 2>&1 | tee
$INSTALLDIR/lldb_test_out.log || true
lldb_failures=`grep -E "^RESULT:" lldb_test_out.log | grep failures | awk
'{count+=$5} END {print count}'` || true
lldb_errors=`grep -E "^RESULT:" lldb_test_out.log | grep errors | awk
'{count+=$7} END {print count}'` || true
lldb_passes=`grep -E "^RESULT: " lldb_test_out.log | sed 's/(//' | awk
'{count+=$3} END {print count}'` || true
lldb_total=`grep -E "^Ran [0-9]+ tests? in" lldb_test_out.log | awk
'{count+=$2} END {print count}'`
And get the correct totals:
lldb_failures=2
lldb_errors=0
lldb_passes=1143
lldb_total=1376
Now it seems we are back to the broken behavior of dosep.py where there's no
way to count the correct totals since it seems to forget to count 25% of the
test results. Only now I have no workaround, because even dotest.py can't
report the changes correctly. Please revert this so I can use dosep.py as
before, or fix dotest.py to count correctly.
Thank you,
-Dawn
Users:
tfiala (Author)
dawn (Auditor)
http://reviews.llvm.org/rL246794
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [Diffusion] rL246794: Roll dosep.py parallel test runner into dotest.py command line
dawn added a comment. I really liked that dosep.py -s and dotest.py would report the run of each test case: Collected 6 tests 1: test_double_type_from_block_with_dsym (TestFloatTypes.FloatTypesTestCase) Test that double-type variables are displayed correctly from a block. ... ok 2: test_double_type_with_dsym (TestFloatTypes.FloatTypesTestCase) Test that double-type variables are displayed correctly. ... ok 3: test_double_type_with_dwarf (TestFloatTypes.FloatTypesTestCase) Test that double-type variables are displayed correctly. ... ok 4: test_float_type_from_block_with_dsym (TestFloatTypes.FloatTypesTestCase) Test that float-type variables are displayed correctly from a block. ... ok 5: test_float_type_with_dsym (TestFloatTypes.FloatTypesTestCase) Test that float-type variables are displayed correctly. ... ok 6: test_float_type_with_dwarf (TestFloatTypes.FloatTypesTestCase) Test that float-type variables are displayed correctly. ... ok -- Ran 6 tests in 6.844s RESULT: PASSED (6 passes, 0 failures, 0 errors, 0 skipped, 0 expected failures, 0 unexpected successes) [TestFloatTypes.py PASSED] I would like to have that back please. Users: tfiala (Author) dawn (Auditor) http://reviews.llvm.org/rL246794 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [Diffusion] rL246794: Roll dosep.py parallel test runner into dotest.py command line
To be honest I think grepping the output is the wrong way to go about counting the tests. If there's a regression in that you no longer have access to a piece of information that you need, then we should fix it by printing the value you need. Log scraping is kind of a horrible thing to do, because it means you are going to be broken by changes to the format of the output, and it will hold back progress on the test suite making real improvements in maintainability and performance because all the different people doing their own custom log scraping will get upset if anything breaks. Anyone who has worked on the test suite can vouch for the fact that it is in need of some major love, and if that means a transition period where things are a little wonky, and we lose some things only to get them back later, I'm ok with that. On Fri, Sep 4, 2015 at 11:04 AM Dawn Perchik via lldb-commits < lldb-commits@lists.llvm.org> wrote: > dawn added a comment. > > I really liked that dosep.py -s and dotest.py would report the run of each > test case: > > Collected 6 tests > > 1: test_double_type_from_block_with_dsym > (TestFloatTypes.FloatTypesTestCase) > Test that double-type variables are displayed correctly from a block. > ... ok > 2: test_double_type_with_dsym (TestFloatTypes.FloatTypesTestCase) > Test that double-type variables are displayed correctly. ... ok > 3: test_double_type_with_dwarf (TestFloatTypes.FloatTypesTestCase) > Test that double-type variables are displayed correctly. ... ok > 4: test_float_type_from_block_with_dsym > (TestFloatTypes.FloatTypesTestCase) > Test that float-type variables are displayed correctly from a block. ... > ok > 5: test_float_type_with_dsym (TestFloatTypes.FloatTypesTestCase) > Test that float-type variables are displayed correctly. ... ok > 6: test_float_type_with_dwarf (TestFloatTypes.FloatTypesTestCase) > Test that float-type variables are displayed correctly. ... ok > > -- > Ran 6 tests in 6.844s > > RESULT: PASSED (6 passes, 0 failures, 0 errors, 0 skipped, 0 expected > failures, 0 unexpected successes) > > [TestFloatTypes.py PASSED] > > I would like to have that back please. > > > Users: > tfiala (Author) > dawn (Auditor) > > http://reviews.llvm.org/rL246794 > > > > ___ > lldb-commits mailing list > lldb-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [Diffusion] rL246794: Roll dosep.py parallel test runner into dotest.py command line
tfiala added a comment. Dawn, the output supported by the command shouldn't have been changed. I'll have a peek at what may have caused that to happen. All this change was trying to do was stop the need to call dosep and roll that behavior into dotest. Zachary, I'm in the process of add xUnit (and other pluggable) output support so we can flip a flag and have traditional build/test bots generate test result reports. Users: tfiala (Author) dawn (Auditor) http://reviews.llvm.org/rL246794 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12634: Fix -data-evaluate-expression for array.
ki.stfu requested changes to this revision.
ki.stfu added a comment.
This revision now requires changes to proceed.
Source code looks good but please move the test to TestMiData.py.
Comment at: test/tools/lldb-mi/variable/TestMiVar.py:39-42
@@ -38,2 +38,6 @@
self.expect("\^error,msg=\"Could not evaluate expression\"")
+
+# Check 2d array
+self.runCmd("-data-evaluate-expression g_blk")
+self.expect("\^done,value=\"\{\[0\] = \{\[0\] = 1, \[1\] = 2, \[2\] =
3\}, \[1\] = \{\[0\] = 4, \[1\] = 5, \[2\] = 6\}\}\"")
Please move it to a separate @lldmi_test test in data/TestMiData.py
Comment at: test/tools/lldb-mi/variable/main.cpp:105-110
@@ -103,2 +104,8 @@
int a = 10, b = 20;
+g_blk[0][0] = 1;
+g_blk[0][1] = 2;
+g_blk[0][2] = 3;
+g_blk[1][0] = 4;
+g_blk[1][1] = 5;
+g_blk[1][2] = 6;
s_MyVar = a + b;
Move it to data/main.cpp and create a separate function for that
(data_evaluate_expression_test, for example)
http://reviews.llvm.org/D12634
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D12641: Work around a race condition in lldbtest.py for Windows.
amccarth created this revision. amccarth added a reviewer: zturner. amccarth added a subscriber: lldb-commits. Allows about 10 passing tests to succeed rather than fail due to log file juggling. http://reviews.llvm.org/D12641 Files: test/lldbtest.py Index: test/lldbtest.py === --- test/lldbtest.py +++ test/lldbtest.py @@ -1791,7 +1791,12 @@ else: # success! (and we don't want log files) delete log files for log_file in log_files_for_this_test: -os.unlink(log_file) +try: +os.unlink(log_file) +except: +# This can be racey on Windows, so sleep and try again. +time.sleep(0.5) +os.unlink(log_file) # # Config. methods supported through a plugin interface Index: test/lldbtest.py === --- test/lldbtest.py +++ test/lldbtest.py @@ -1791,7 +1791,12 @@ else: # success! (and we don't want log files) delete log files for log_file in log_files_for_this_test: -os.unlink(log_file) +try: +os.unlink(log_file) +except: +# This can be racey on Windows, so sleep and try again. +time.sleep(0.5) +os.unlink(log_file) # # Config. methods supported through a plugin interface ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [Diffusion] rL246794: Roll dosep.py parallel test runner into dotest.py command line
On Fri, Sep 04, 2015 at 06:17:03PM +, Zachary Turner wrote: > To be honest I think grepping the output is the wrong way to go about > counting the tests. > [...] Log scraping is kind of a horrible thing to do, Agreed, but it was the only way to get correct totals. I would love for dosep.py to have been able to count the results correctly so I wouldn't have had to resort to "log scraping". dotest.py at least used to be able to count the totals correctly, but no longer can since it now inherrited the same bug that dosep.py had. ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [Diffusion] rL246794: Roll dosep.py parallel test runner into dotest.py command line
I guess the thing to do in that case would be to fix it. I know priorities and all, but I don't want to hold back progress supporting an external workflow. In any case, Todd says that the output shouldn't have changed, so it may still be that you can continue doing this (for now). But at some point you may have to jump in and fix the totals if the ability to scrape the logs goes away, and the reported total is still wrong. On Fri, Sep 4, 2015 at 11:41 AM wrote: > On Fri, Sep 04, 2015 at 06:17:03PM +, Zachary Turner wrote: > > To be honest I think grepping the output is the wrong way to go about > > counting the tests. > > [...] Log scraping is kind of a horrible thing to do, > > Agreed, but it was the only way to get correct totals. I would love for > dosep.py to have been able to count the results correctly so I wouldn't > have had to resort to "log scraping". dotest.py at least used to be > able to count the totals correctly, but no longer can since it now > inherrited the same bug that dosep.py had. > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12602: Separate ClangExpressionVariable from ExpressionVariable
spyffe added a comment. Working on that now. I have to be careful not just to stuff ClangExpressionVariable* into ExpressionVariableSP, but to use shared_from_this, otherwise I get crashes in the testsuite. I'll update this patch once I get that cleaned up. http://reviews.llvm.org/D12602 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [Diffusion] rL246794: Roll dosep.py parallel test runner into dotest.py command line
On Fri, Sep 04, 2015 at 06:25:44PM +, Todd Fiala wrote: > tfiala added a comment. > > Dawn, the output supported by the command shouldn't have been changed. I'll > have a peek at what may have caused that to happen. All this change was > trying to do was stop the need to call dosep and roll that behavior into > dotest. Both of these commands: ./dosep.py -s --options "-v --executable $INSTALLDIR/bin/lldb" ./dotest.py -v --executable $INSTALLDIR/bin/lldb used to print results like the following: Collected 6 tests 1: test_double_type_from_block_with_dsym (TestFloatTypes.FloatTypesTestCase) Test that double-type variables are displayed correctly from a block. ... ok 2: test_double_type_with_dsym (TestFloatTypes.FloatTypesTestCase) Test that double-type variables are displayed correctly. ... ok 3: test_double_type_with_dwarf (TestFloatTypes.FloatTypesTestCase) Test that double-type variables are displayed correctly. ... ok 4: test_float_type_from_block_with_dsym (TestFloatTypes.FloatTypesTestCase) Test that float-type variables are displayed correctly from a block. ... ok 5: test_float_type_with_dsym (TestFloatTypes.FloatTypesTestCase) Test that float-type variables are displayed correctly. ... ok 6: test_float_type_with_dwarf (TestFloatTypes.FloatTypesTestCase) Test that float-type variables are displayed correctly. ... ok -- Ran 6 tests in 6.844s RESULT: PASSED (6 passes, 0 failures, 0 errors, 0 skipped, 0 expected failures, 0 unexpected successes) [TestFloatTypes.py PASSED] Now there is no equivelent to "dosep.py -s", and: ./dotest.py -v --executable $INSTALLDIR/bin/lldb prints results like the following: Testing: 395 test suites, 8 threads 0 out of 395 test suites processed - ['./dotest.py', '-v', '--executable', '/Users/testuser/build/workspace/LLVM-Clang-LLDB_master_release_OSX/llvm/build_ninja/lldb_redist/usr/local/bin/lldb'] 1 out of 395 test suites processed - TestCompileRunToBreakpointTurnaround.py [...] 395 out of 395 test suites processed - TestRecursiveTypes.py Ran 395 test suites (0 failed) (0.00%) Ran 826 test cases (0 failed) (0.00%) So we no longer have info on what tests ran, can't figure out what tests were skipped, can't calculate the correct totals, etc. ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12615: Teach utilsOsType about NetBSD
krytarowski added a comment. $ python2.7 Python 2.7.10 (default, Jul 2 2015, 13:17:37) [GCC 4.8.4] on netbsd7 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> print sys.platform netbsd7 >>> pr Repository: rL LLVM http://reviews.llvm.org/D12615 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12602: Separate ClangExpressionVariable from ExpressionVariable
spyffe updated this revision to Diff 34055.
spyffe added a comment.
Applied Jim's suggestion that FindVariableInList return a
ClangExpressionVariable *. Also fixed some places where we should have called
shared_from_this instead of creating a new shared pointer.
http://reviews.llvm.org/D12602
Files:
include/lldb/Core/ValueObject.h
include/lldb/Expression/ClangExpressionDeclMap.h
include/lldb/Expression/ClangFunction.h
include/lldb/Expression/ClangPersistentVariables.h
include/lldb/Expression/ClangUserExpression.h
include/lldb/Expression/ClangUtilityFunction.h
include/lldb/Expression/ExpressionVariable.h
include/lldb/Expression/Materializer.h
include/lldb/Target/StopInfo.h
include/lldb/Target/Thread.h
include/lldb/Target/ThreadPlan.h
include/lldb/Target/ThreadPlanCallUserExpression.h
include/lldb/lldb-forward.h
source/API/SBFrame.cpp
source/Breakpoint/BreakpointLocation.cpp
source/Core/FormatEntity.cpp
source/Core/ValueObject.cpp
source/Expression/ClangExpressionDeclMap.cpp
source/Expression/ClangPersistentVariables.cpp
source/Expression/ClangUserExpression.cpp
source/Expression/ExpressionVariable.cpp
source/Expression/Materializer.cpp
source/Plugins/ExpressionParser/Clang/ClangExpressionVariable.cpp
source/Plugins/ExpressionParser/Clang/ClangExpressionVariable.h
source/Target/ABI.cpp
source/Target/StopInfo.cpp
source/Target/Target.cpp
source/Target/Thread.cpp
Index: include/lldb/lldb-forward.h
===
--- include/lldb/lldb-forward.h
+++ include/lldb/lldb-forward.h
@@ -52,8 +52,6 @@
class ClangExpressionDeclMap;
class ClangExpressionParser;
class ClangExpressionVariable;
-class ClangExpressionVariableList;
-class ClangExpressionVariableList;
class ClangExpressionVariables;
class ClangFunction;
class ClangModulesDeclVendor;
@@ -95,6 +93,8 @@
class ExecutionContextRef;
class ExecutionContextRefLocker;
class ExecutionContextScope;
+class ExpressionVariable;
+class ExpressionVariableList;
class File;
class FileSpec;
class FileSpecList;
@@ -305,7 +305,6 @@
typedef std::unique_ptr ClangASTContextUP;
typedef std::unique_ptr ClangASTImporterUP;
typedef std::unique_ptr ClangASTSourceUP;
-typedef std::shared_ptr ClangExpressionVariableSP;
typedef std::unique_ptr ClangModulesDeclVendorUP;
typedef std::unique_ptr ClangPersistentVariablesUP;
typedef std::shared_ptr ClangUserExpressionSP;
@@ -323,6 +322,7 @@
typedef std::unique_ptr DynamicLoaderUP;
typedef std::shared_ptr EventSP;
typedef std::shared_ptr ExecutionContextRefSP;
+typedef std::shared_ptr ExpressionVariableSP;
typedef std::shared_ptr FileSP;
typedef std::shared_ptr FunctionSP;
typedef std::shared_ptr FuncUnwindersSP;
Index: include/lldb/Target/ThreadPlanCallUserExpression.h
===
--- include/lldb/Target/ThreadPlanCallUserExpression.h
+++ include/lldb/Target/ThreadPlanCallUserExpression.h
@@ -52,7 +52,7 @@
m_manage_materialization = true;
}
-lldb::ClangExpressionVariableSP
+lldb::ExpressionVariableSP
GetExpressionVariable() override
{
return m_result_var_sp;
@@ -64,7 +64,7 @@
// User expression the initiated this ThreadPlan
// lives as long as the thread plan does.
bool m_manage_materialization = false;
-lldb::ClangExpressionVariableSP m_result_var_sp; // If we are left to manage the materialization,
+lldb::ExpressionVariableSP m_result_var_sp; // If we are left to manage the materialization,
// then stuff the result expression variable here.
DISALLOW_COPY_AND_ASSIGN (ThreadPlanCallUserExpression);
Index: include/lldb/Target/ThreadPlan.h
===
--- include/lldb/Target/ThreadPlan.h
+++ include/lldb/Target/ThreadPlan.h
@@ -519,10 +519,10 @@
// the user regained control at that point) a subsequent process control command step/continue/etc. might
// complete the expression evaluations. If so, the result of the expression evaluation will show up here.
-virtual lldb::ClangExpressionVariableSP
+virtual lldb::ExpressionVariableSP
GetExpressionVariable ()
{
-return lldb::ClangExpressionVariableSP();
+return lldb::ExpressionVariableSP();
}
// If a thread plan stores the state before it was run, then you might
Index: include/lldb/Target/Thread.h
===
--- include/lldb/Target/Thread.h
+++ include/lldb/Target/Thread.h
@@ -988,11 +988,11 @@
/// Gets the outer-most expression variable from the completed plans
///
/// @return
-///
Re: [Lldb-commits] [PATCH] D12602: Separate ClangExpressionVariable from ExpressionVariable
jingham added a comment. That look good. There's one place (noted inline) where you are missing a newline at the end of a file. Fix that and it's good to go. Comment at: source/Expression/ExpressionVariable.cpp:32-33 @@ +31,2 @@ +return NULL; +} \ No newline at end of file Add missing newline. http://reviews.llvm.org/D12602 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [Diffusion] rL246794: Roll dosep.py parallel test runner into dotest.py command line
On Fri, Sep 04, 2015 at 06:25:44PM +, Todd Fiala wrote: > tfiala added a comment. > > Dawn, the output supported by the command shouldn't have been changed. I'll > have a peek at what may have caused that to happen. All this change was > trying to do was stop the need to call dosep and roll that behavior into > dotest. Can you add the 'dosep.py -s -o "-v"' behavior to 'dotest.py -v'? I think that may be all that's needed in order to show the same output as before with all the desired details. Note: before the -s option was added to dosep.py, 'dosep.py -o "-v"' would only show the info that 'dotest.py -v' shows now (after your change). Afer the -s option was added to dosep.py, 'dosep.py -s -o "-v"' would report the same info as 'dotest.py -v' did before your change. I.e. dosep.py's -s option may be the key to fixing the regressions in 'dotest.py -v'. Thanks for looking into this! -Dawn ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [Diffusion] rL246794: Roll dosep.py parallel test runner into dotest.py command line
> Now there is no equivelent to "dosep.py -s", and: >./dotest.py -v --executable $INSTALLDIR/bin/lldb All of dosep's args moved over to dotest. I think if you wanted dosep.py -s behavior, you only need to use --output-on-success (long form of what used to be -s in dosep I believe). The reason I couldn't maintain it as -s is that dotest.py already had a -s abbreviation (for session dir specification). On Fri, Sep 4, 2015 at 12:02 PM, wrote: > On Fri, Sep 04, 2015 at 06:25:44PM +, Todd Fiala wrote: > > tfiala added a comment. > > > > Dawn, the output supported by the command shouldn't have been changed. > I'll have a peek at what may have caused that to happen. All this change > was trying to do was stop the need to call dosep and roll that behavior > into dotest. > > Both of these commands: > ./dosep.py -s --options "-v --executable $INSTALLDIR/bin/lldb" > ./dotest.py -v --executable $INSTALLDIR/bin/lldb > > used to print results like the following: > Collected 6 tests > > 1: test_double_type_from_block_with_dsym > (TestFloatTypes.FloatTypesTestCase) > Test that double-type variables are displayed correctly from a > block. ... ok > 2: test_double_type_with_dsym (TestFloatTypes.FloatTypesTestCase) > Test that double-type variables are displayed correctly. ... ok > 3: test_double_type_with_dwarf (TestFloatTypes.FloatTypesTestCase) > Test that double-type variables are displayed correctly. ... ok > 4: test_float_type_from_block_with_dsym > (TestFloatTypes.FloatTypesTestCase) > Test that float-type variables are displayed correctly from a block. > ... ok > 5: test_float_type_with_dsym (TestFloatTypes.FloatTypesTestCase) > Test that float-type variables are displayed correctly. ... ok > 6: test_float_type_with_dwarf (TestFloatTypes.FloatTypesTestCase) > Test that float-type variables are displayed correctly. ... ok > > -- > Ran 6 tests in 6.844s > > RESULT: PASSED (6 passes, 0 failures, 0 errors, 0 skipped, 0 > expected failures, 0 unexpected successes) > > [TestFloatTypes.py PASSED] > > Now there is no equivelent to "dosep.py -s", and: > ./dotest.py -v --executable $INSTALLDIR/bin/lldb > > prints results like the following: > Testing: 395 test suites, 8 threads > > 0 out of 395 test suites processed - ['./dotest.py', '-v', > '--executable', > > '/Users/testuser/build/workspace/LLVM-Clang-LLDB_master_release_OSX/llvm/build_ninja/lldb_redist/usr/local/bin/lldb'] > > 1 out of 395 test suites processed - > TestCompileRunToBreakpointTurnaround.py > [...] > 395 out of 395 test suites processed - TestRecursiveTypes.py > Ran 395 test suites (0 failed) (0.00%) > Ran 826 test cases (0 failed) (0.00%) > > So we no longer have info on what tests ran, can't figure out what > tests were skipped, can't calculate the correct totals, etc. > -- -Todd ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [Diffusion] rL246794: Roll dosep.py parallel test runner into dotest.py command line
I see how that could have been confusing. I should have called that out more. On Fri, Sep 4, 2015 at 12:40 PM, Todd Fiala wrote: > > Now there is no equivelent to "dosep.py -s", and: > >./dotest.py -v --executable $INSTALLDIR/bin/lldb > > All of dosep's args moved over to dotest. I think if you wanted dosep.py > -s behavior, you only need to use --output-on-success (long form of what > used to be -s in dosep I believe). The reason I couldn't maintain it as -s > is that dotest.py already had a -s abbreviation (for session dir > specification). > > On Fri, Sep 4, 2015 at 12:02 PM, wrote: > >> On Fri, Sep 04, 2015 at 06:25:44PM +, Todd Fiala wrote: >> > tfiala added a comment. >> > >> > Dawn, the output supported by the command shouldn't have been changed. >> I'll have a peek at what may have caused that to happen. All this change >> was trying to do was stop the need to call dosep and roll that behavior >> into dotest. >> >> Both of these commands: >> ./dosep.py -s --options "-v --executable $INSTALLDIR/bin/lldb" >> ./dotest.py -v --executable $INSTALLDIR/bin/lldb >> >> used to print results like the following: >> Collected 6 tests >> >> 1: test_double_type_from_block_with_dsym >> (TestFloatTypes.FloatTypesTestCase) >> Test that double-type variables are displayed correctly from a >> block. ... ok >> 2: test_double_type_with_dsym (TestFloatTypes.FloatTypesTestCase) >> Test that double-type variables are displayed correctly. ... ok >> 3: test_double_type_with_dwarf (TestFloatTypes.FloatTypesTestCase) >> Test that double-type variables are displayed correctly. ... ok >> 4: test_float_type_from_block_with_dsym >> (TestFloatTypes.FloatTypesTestCase) >> Test that float-type variables are displayed correctly from a block. >> ... ok >> 5: test_float_type_with_dsym (TestFloatTypes.FloatTypesTestCase) >> Test that float-type variables are displayed correctly. ... ok >> 6: test_float_type_with_dwarf (TestFloatTypes.FloatTypesTestCase) >> Test that float-type variables are displayed correctly. ... ok >> >> -- >> Ran 6 tests in 6.844s >> >> RESULT: PASSED (6 passes, 0 failures, 0 errors, 0 skipped, 0 >> expected failures, 0 unexpected successes) >> >> [TestFloatTypes.py PASSED] >> >> Now there is no equivelent to "dosep.py -s", and: >> ./dotest.py -v --executable $INSTALLDIR/bin/lldb >> >> prints results like the following: >> Testing: 395 test suites, 8 threads >> >> 0 out of 395 test suites processed - ['./dotest.py', '-v', >> '--executable', >> >> '/Users/testuser/build/workspace/LLVM-Clang-LLDB_master_release_OSX/llvm/build_ninja/lldb_redist/usr/local/bin/lldb'] >> >> 1 out of 395 test suites processed - >> TestCompileRunToBreakpointTurnaround.py >> [...] >> 395 out of 395 test suites processed - TestRecursiveTypes.py >> Ran 395 test suites (0 failed) (0.00%) >> Ran 826 test cases (0 failed) (0.00%) >> >> So we no longer have info on what tests ran, can't figure out what >> tests were skipped, can't calculate the correct totals, etc. >> > > > > -- > -Todd > -- -Todd ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [Diffusion] rL246794: Roll dosep.py parallel test runner into dotest.py command line
Please try: ./dotest.py --output-on-success -v --executable $INSTALLDIR/bin/lldb I think you'll find that is identical output to what used to be this: ./dosep.py -s --options "-v --executable $INSTALLDIR/bin/lldb" If you find differently, please let me know. I couldn't maintain the '-s' mapping for the dosep option because it collided with an existing dotest.py option for session directory specification. I'll wait to hear if that works for you. (I tested it when I added it, and I didn't mess with the logic aside from the flag name, so if it is broken I definitely want to fix it --- you just have to use a different flag name). On Fri, Sep 4, 2015 at 12:35 PM, wrote: > On Fri, Sep 04, 2015 at 06:25:44PM +, Todd Fiala wrote: > > tfiala added a comment. > > > > Dawn, the output supported by the command shouldn't have been changed. > I'll have a peek at what may have caused that to happen. All this change > was trying to do was stop the need to call dosep and roll that behavior > into dotest. > > Can you add the 'dosep.py -s -o "-v"' behavior to 'dotest.py -v'? I > think that may be all that's needed in order to show the same output as > before with all the desired details. Note: before the -s option was > added to dosep.py, 'dosep.py -o "-v"' would only show the info that > 'dotest.py -v' shows now (after your change). Afer the -s option was > added to dosep.py, 'dosep.py -s -o "-v"' would report the same info as > 'dotest.py -v' did before your change. I.e. dosep.py's -s option may be > the key to fixing the regressions in 'dotest.py -v'. > > Thanks for looking into this! > -Dawn > -- -Todd ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12641: Work around a race condition in lldbtest.py for Windows.
sas added a subscriber: sas. sas added a comment. Can you just explain why this race happens? Otherwise, looks good. http://reviews.llvm.org/D12641 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [Diffusion] rL246794: Roll dosep.py parallel test runner into dotest.py command line
On Fri, Sep 4, 2015 at 12:40 PM Todd Fiala wrote: > > Now there is no equivelent to "dosep.py -s", and: > >./dotest.py -v --executable $INSTALLDIR/bin/lldb > > All of dosep's args moved over to dotest. I think if you wanted dosep.py > -s behavior, you only need to use --output-on-success (long form of what > used to be -s in dosep I believe). The reason I couldn't maintain it as -s > is that dotest.py already had a -s abbreviation (for session dir > specification). > One reason I would like to move towards fewer options in dotest, it's crazy how many options there are. I'm willing to bet 80% of them are not used by anyone and we could probably remove them. Maybe after you finish a lot of the cleanup work and we decide on a final vision of how everything should be structured, we can do a pass over the options and decide which ones we can remove. ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [Diffusion] rL246794: Roll dosep.py parallel test runner into dotest.py command line
Yeah I'm actually hoping that once we move over to a test event stream that can be formatted with a customizable formatter, we can pretty much start deprecating the other output streams aside from the pure test run stdout/stderr. On Fri, Sep 4, 2015 at 12:45 PM, Zachary Turner wrote: > > > On Fri, Sep 4, 2015 at 12:40 PM Todd Fiala wrote: > >> > Now there is no equivelent to "dosep.py -s", and: >> >./dotest.py -v --executable $INSTALLDIR/bin/lldb >> >> All of dosep's args moved over to dotest. I think if you wanted dosep.py >> -s behavior, you only need to use --output-on-success (long form of what >> used to be -s in dosep I believe). The reason I couldn't maintain it as -s >> is that dotest.py already had a -s abbreviation (for session dir >> specification). >> > > One reason I would like to move towards fewer options in dotest, it's > crazy how many options there are. I'm willing to bet 80% of them are not > used by anyone and we could probably remove them. > > Maybe after you finish a lot of the cleanup work and we decide on a final > vision of how everything should be structured, we can do a pass over the > options and decide which ones we can remove. > -- -Todd ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [Diffusion] rL246794: Roll dosep.py parallel test runner into dotest.py command line
On Fri, Sep 04, 2015 at 12:40:12PM -0700, Todd Fiala wrote: > > Now there is no equivelent to "dosep.py -s", and: > >./dotest.py -v --executable $INSTALLDIR/bin/lldb > > All of dosep's args moved over to dotest. I think if you wanted dosep.py > -s behavior, you only need to use --output-on-success (long form of what > used to be -s in dosep I believe). The reason I couldn't maintain it as -s > is that dotest.py already had a -s abbreviation (for session dir > specification). Thanks! I'll give --output-on-success a try... ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12602: Separate ClangExpressionVariable from ExpressionVariable
spyffe updated this revision to Diff 34061.
spyffe added a comment.
Added a newline to the end of ExpressionVariable.cpp
http://reviews.llvm.org/D12602
Files:
include/lldb/Core/ValueObject.h
include/lldb/Expression/ClangExpressionDeclMap.h
include/lldb/Expression/ClangFunction.h
include/lldb/Expression/ClangPersistentVariables.h
include/lldb/Expression/ClangUserExpression.h
include/lldb/Expression/ClangUtilityFunction.h
include/lldb/Expression/ExpressionVariable.h
include/lldb/Expression/Materializer.h
include/lldb/Target/StopInfo.h
include/lldb/Target/Thread.h
include/lldb/Target/ThreadPlan.h
include/lldb/Target/ThreadPlanCallUserExpression.h
include/lldb/lldb-forward.h
source/API/SBFrame.cpp
source/Breakpoint/BreakpointLocation.cpp
source/Core/FormatEntity.cpp
source/Core/ValueObject.cpp
source/Expression/ClangExpressionDeclMap.cpp
source/Expression/ClangPersistentVariables.cpp
source/Expression/ClangUserExpression.cpp
source/Expression/ExpressionVariable.cpp
source/Expression/Materializer.cpp
source/Plugins/ExpressionParser/Clang/ClangExpressionVariable.cpp
source/Plugins/ExpressionParser/Clang/ClangExpressionVariable.h
source/Target/ABI.cpp
source/Target/StopInfo.cpp
source/Target/Target.cpp
source/Target/Thread.cpp
Index: include/lldb/lldb-forward.h
===
--- include/lldb/lldb-forward.h
+++ include/lldb/lldb-forward.h
@@ -52,8 +52,6 @@
class ClangExpressionDeclMap;
class ClangExpressionParser;
class ClangExpressionVariable;
-class ClangExpressionVariableList;
-class ClangExpressionVariableList;
class ClangExpressionVariables;
class ClangFunction;
class ClangModulesDeclVendor;
@@ -95,6 +93,8 @@
class ExecutionContextRef;
class ExecutionContextRefLocker;
class ExecutionContextScope;
+class ExpressionVariable;
+class ExpressionVariableList;
class File;
class FileSpec;
class FileSpecList;
@@ -305,7 +305,6 @@
typedef std::unique_ptr ClangASTContextUP;
typedef std::unique_ptr ClangASTImporterUP;
typedef std::unique_ptr ClangASTSourceUP;
-typedef std::shared_ptr ClangExpressionVariableSP;
typedef std::unique_ptr ClangModulesDeclVendorUP;
typedef std::unique_ptr ClangPersistentVariablesUP;
typedef std::shared_ptr ClangUserExpressionSP;
@@ -323,6 +322,7 @@
typedef std::unique_ptr DynamicLoaderUP;
typedef std::shared_ptr EventSP;
typedef std::shared_ptr ExecutionContextRefSP;
+typedef std::shared_ptr ExpressionVariableSP;
typedef std::shared_ptr FileSP;
typedef std::shared_ptr FunctionSP;
typedef std::shared_ptr FuncUnwindersSP;
Index: include/lldb/Target/ThreadPlanCallUserExpression.h
===
--- include/lldb/Target/ThreadPlanCallUserExpression.h
+++ include/lldb/Target/ThreadPlanCallUserExpression.h
@@ -52,7 +52,7 @@
m_manage_materialization = true;
}
-lldb::ClangExpressionVariableSP
+lldb::ExpressionVariableSP
GetExpressionVariable() override
{
return m_result_var_sp;
@@ -64,7 +64,7 @@
// User expression the initiated this ThreadPlan
// lives as long as the thread plan does.
bool m_manage_materialization = false;
-lldb::ClangExpressionVariableSP m_result_var_sp; // If we are left to manage the materialization,
+lldb::ExpressionVariableSP m_result_var_sp; // If we are left to manage the materialization,
// then stuff the result expression variable here.
DISALLOW_COPY_AND_ASSIGN (ThreadPlanCallUserExpression);
Index: include/lldb/Target/ThreadPlan.h
===
--- include/lldb/Target/ThreadPlan.h
+++ include/lldb/Target/ThreadPlan.h
@@ -519,10 +519,10 @@
// the user regained control at that point) a subsequent process control command step/continue/etc. might
// complete the expression evaluations. If so, the result of the expression evaluation will show up here.
-virtual lldb::ClangExpressionVariableSP
+virtual lldb::ExpressionVariableSP
GetExpressionVariable ()
{
-return lldb::ClangExpressionVariableSP();
+return lldb::ExpressionVariableSP();
}
// If a thread plan stores the state before it was run, then you might
Index: include/lldb/Target/Thread.h
===
--- include/lldb/Target/Thread.h
+++ include/lldb/Target/Thread.h
@@ -988,11 +988,11 @@
/// Gets the outer-most expression variable from the completed plans
///
/// @return
-/// A ClangExpressionVariableSP, either empty if there is no
+/// A ExpressionVariableSP, either empty if there is no
/// plan com
Re: [Lldb-commits] [PATCH] D12641: Work around a race condition in lldbtest.py for Windows.
Windows is well-known (I wouldn't say documented necessarily, but it seems everyone has run into this problem before) where there is a very short window after a process exits where some of the handles that were used by the file (e.g. open files, the image file itself, etc) are still locked by the operating system. It doesn't happen every time, or even on every machine (I've never been able to reproduce Adrian's problem on my Windows 10 machine, for example) Maybe it's due to the search indexer, maybe it's due to antivirus, maybe it's due to a bug in the kernel. LLVM just had a similar problem just this week and fixed it with a similar workaround ( http://llvm.org/viewvc/llvm-project?rev=246708&view=rev) On Fri, Sep 4, 2015 at 12:45 PM Stephane Sezer wrote: > sas added a subscriber: sas. > sas added a comment. > > Can you just explain why this race happens? > Otherwise, looks good. > > > http://reviews.llvm.org/D12641 > > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12641: Work around a race condition in lldbtest.py for Windows.
zturner added a subscriber: zturner. zturner added a comment. Windows is well-known (I wouldn't say documented necessarily, but it seems everyone has run into this problem before) where there is a very short window after a process exits where some of the handles that were used by the file (e.g. open files, the image file itself, etc) are still locked by the operating system. It doesn't happen every time, or even on every machine (I've never been able to reproduce Adrian's problem on my Windows 10 machine, for example) Maybe it's due to the search indexer, maybe it's due to antivirus, maybe it's due to a bug in the kernel. LLVM just had a similar problem just this week and fixed it with a similar workaround ( http://llvm.org/viewvc/llvm-project?rev=246708&view=rev) http://reviews.llvm.org/D12641 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12641: Work around a race condition in lldbtest.py for Windows.
amccarth updated this revision to Diff 34063. amccarth added a comment. I've put more detail in the comment. http://reviews.llvm.org/D12641 Files: test/lldbtest.py Index: test/lldbtest.py === --- test/lldbtest.py +++ test/lldbtest.py @@ -1791,7 +1791,17 @@ else: # success! (and we don't want log files) delete log files for log_file in log_files_for_this_test: -os.unlink(log_file) +try: +os.unlink(log_file) +except: +# We've seen consistent unlink failures on Windows, perhaps because the +# just-created log file is being scanned by anti-virus. Empirically, this +# sleep-and-retry approach allows tests to succeed much more reliably. +# Attempts to figure out exactly what process was still holding a file handle +# have failed because running instrumentation like Process Monitor seems to +# slow things down enough that the problem becomes much less consistent. +time.sleep(0.5) +os.unlink(log_file) # # Config. methods supported through a plugin interface Index: test/lldbtest.py === --- test/lldbtest.py +++ test/lldbtest.py @@ -1791,7 +1791,17 @@ else: # success! (and we don't want log files) delete log files for log_file in log_files_for_this_test: -os.unlink(log_file) +try: +os.unlink(log_file) +except: +# We've seen consistent unlink failures on Windows, perhaps because the +# just-created log file is being scanned by anti-virus. Empirically, this +# sleep-and-retry approach allows tests to succeed much more reliably. +# Attempts to figure out exactly what process was still holding a file handle +# have failed because running instrumentation like Process Monitor seems to +# slow things down enough that the problem becomes much less consistent. +time.sleep(0.5) +os.unlink(log_file) # # Config. methods supported through a plugin interface ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [Diffusion] rL246794: Roll dosep.py parallel test runner into dotest.py command line
On Fri, Sep 04, 2015 at 12:44:36PM -0700, Todd Fiala wrote: > Please try: > > ./dotest.py --output-on-success -v --executable $INSTALLDIR/bin/lldb Yes, this appears to work. With this, I'm now back up to my old totals :) lldb_failures=0 lldb_errors=0 lldb_passes=1146 lldb_total=1378 Thank you!! I'd recommend turning --output-on-success on when -v is used so that the loss of information doesn't appear as a regression. That way, dotest.py -v will always show the same detailed info in both single and multithreaded modes. > I couldn't maintain the '-s' > mapping for the dosep option because it collided with an existing dotest.py > option for session directory specification. Understood. I don't think a short option for --output-on-success is needed if -v turns it on. A short option for --test-subdir would be useful however. Looks like these short options are still available: BHIJKLMOQUVWYZjoz. -z seems as good a choice as any :) ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [Diffusion] rL246794: Roll dosep.py parallel test runner into dotest.py command line
dawn accepted this commit. dawn added a comment. Apparently now you must use: ./dotest.py --output-on-success -v --executable $INSTALLDIR/bin/lldb to see the same detailed output as you used to see with: ./dosep.py -s --options "-v --executable $INSTALLDIR/bin/lldb" or: ./dotest.py -v --executable $INSTALLDIR/bin/lldb So no info is lost, just have to add the extra option --output-on-success. Users: tfiala (Author) dawn (Auditor) http://reviews.llvm.org/rL246794 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12641: Work around a race condition in lldbtest.py for Windows.
sas accepted this revision. sas added a reviewer: sas. sas added a comment. This revision is now accepted and ready to land. Wow, this is funny. Thanks for the explanation @zturner and thanks for adding the comment @amccarth. http://reviews.llvm.org/D12641 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r246870 - Sleep-and-retry after a failure to delete a log file, which may be because antimalware is holding the handle to the just-created file.
Author: amccarth Date: Fri Sep 4 15:48:48 2015 New Revision: 246870 URL: http://llvm.org/viewvc/llvm-project?rev=246870&view=rev Log: Sleep-and-retry after a failure to delete a log file, which may be because antimalware is holding the handle to the just-created file. Differential Revision: http://reviews.llvm.org/D12641 Modified: lldb/trunk/test/lldbtest.py Modified: lldb/trunk/test/lldbtest.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/test/lldbtest.py?rev=246870&r1=246869&r2=246870&view=diff == --- lldb/trunk/test/lldbtest.py (original) +++ lldb/trunk/test/lldbtest.py Fri Sep 4 15:48:48 2015 @@ -1791,7 +1791,17 @@ class Base(unittest2.TestCase): else: # success! (and we don't want log files) delete log files for log_file in log_files_for_this_test: -os.unlink(log_file) +try: +os.unlink(log_file) +except: +# We've seen consistent unlink failures on Windows, perhaps because the +# just-created log file is being scanned by anti-virus. Empirically, this +# sleep-and-retry approach allows tests to succeed much more reliably. +# Attempts to figure out exactly what process was still holding a file handle +# have failed because running instrumentation like Process Monitor seems to +# slow things down enough that the problem becomes much less consistent. +time.sleep(0.5) +os.unlink(log_file) # # Config. methods supported through a plugin interface ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12641: Work around a race condition in lldbtest.py for Windows.
This revision was automatically updated to reflect the committed changes. Closed by commit rL246870: Sleep-and-retry after a failure to delete a log file, which may be because… (authored by amccarth). Changed prior to commit: http://reviews.llvm.org/D12641?vs=34063&id=34071#toc Repository: rL LLVM http://reviews.llvm.org/D12641 Files: lldb/trunk/test/lldbtest.py Index: lldb/trunk/test/lldbtest.py === --- lldb/trunk/test/lldbtest.py +++ lldb/trunk/test/lldbtest.py @@ -1791,7 +1791,17 @@ else: # success! (and we don't want log files) delete log files for log_file in log_files_for_this_test: -os.unlink(log_file) +try: +os.unlink(log_file) +except: +# We've seen consistent unlink failures on Windows, perhaps because the +# just-created log file is being scanned by anti-virus. Empirically, this +# sleep-and-retry approach allows tests to succeed much more reliably. +# Attempts to figure out exactly what process was still holding a file handle +# have failed because running instrumentation like Process Monitor seems to +# slow things down enough that the problem becomes much less consistent. +time.sleep(0.5) +os.unlink(log_file) # # Config. methods supported through a plugin interface Index: lldb/trunk/test/lldbtest.py === --- lldb/trunk/test/lldbtest.py +++ lldb/trunk/test/lldbtest.py @@ -1791,7 +1791,17 @@ else: # success! (and we don't want log files) delete log files for log_file in log_files_for_this_test: -os.unlink(log_file) +try: +os.unlink(log_file) +except: +# We've seen consistent unlink failures on Windows, perhaps because the +# just-created log file is being scanned by anti-virus. Empirically, this +# sleep-and-retry approach allows tests to succeed much more reliably. +# Attempts to figure out exactly what process was still holding a file handle +# have failed because running instrumentation like Process Monitor seems to +# slow things down enough that the problem becomes much less consistent. +time.sleep(0.5) +os.unlink(log_file) # # Config. methods supported through a plugin interface ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r246871 - This patch separates the generic portion of ClangExpressionVariable, which
Author: spyffe Date: Fri Sep 4 15:49:51 2015 New Revision: 246871 URL: http://llvm.org/viewvc/llvm-project?rev=246871&view=rev Log: This patch separates the generic portion of ClangExpressionVariable, which stores information about a variable that different parts of LLDB use, from the compiler-specific portion that only the expression parser cares about. http://reviews.llvm.org/D12602 Modified: lldb/trunk/include/lldb/Core/ValueObject.h lldb/trunk/include/lldb/Expression/ClangExpressionDeclMap.h lldb/trunk/include/lldb/Expression/ClangFunction.h lldb/trunk/include/lldb/Expression/ClangPersistentVariables.h lldb/trunk/include/lldb/Expression/ClangUserExpression.h lldb/trunk/include/lldb/Expression/ClangUtilityFunction.h lldb/trunk/include/lldb/Expression/ExpressionVariable.h lldb/trunk/include/lldb/Expression/Materializer.h lldb/trunk/include/lldb/Target/StopInfo.h lldb/trunk/include/lldb/Target/Thread.h lldb/trunk/include/lldb/Target/ThreadPlan.h lldb/trunk/include/lldb/Target/ThreadPlanCallUserExpression.h lldb/trunk/include/lldb/lldb-forward.h lldb/trunk/lldb.xcodeproj/project.pbxproj lldb/trunk/lldb.xcodeproj/xcshareddata/xcschemes/lldb-tool.xcscheme lldb/trunk/source/API/SBFrame.cpp lldb/trunk/source/Breakpoint/BreakpointLocation.cpp lldb/trunk/source/Core/FormatEntity.cpp lldb/trunk/source/Core/ValueObject.cpp lldb/trunk/source/Expression/ClangExpressionDeclMap.cpp lldb/trunk/source/Expression/ClangPersistentVariables.cpp lldb/trunk/source/Expression/ClangUserExpression.cpp lldb/trunk/source/Expression/ExpressionVariable.cpp lldb/trunk/source/Expression/Materializer.cpp lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionVariable.cpp lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionVariable.h lldb/trunk/source/Target/ABI.cpp lldb/trunk/source/Target/StopInfo.cpp lldb/trunk/source/Target/Target.cpp lldb/trunk/source/Target/Thread.cpp Modified: lldb/trunk/include/lldb/Core/ValueObject.h URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/ValueObject.h?rev=246871&r1=246870&r2=246871&view=diff == --- lldb/trunk/include/lldb/Core/ValueObject.h (original) +++ lldb/trunk/include/lldb/Core/ValueObject.h Fri Sep 4 15:49:51 2015 @@ -1139,7 +1139,7 @@ protected: friend class ValueObjectChild; friend class ClangExpressionDeclMap; // For GetValue -friend class ClangExpressionVariable; // For SetName +friend class ExpressionVariable; // For SetName friend class Target; // For SetName friend class ValueObjectConstResultImpl; friend class ValueObjectSynthetic;// For ClearUserVisibleData Modified: lldb/trunk/include/lldb/Expression/ClangExpressionDeclMap.h URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Expression/ClangExpressionDeclMap.h?rev=246871&r1=246870&r2=246871&view=diff == --- lldb/trunk/include/lldb/Expression/ClangExpressionDeclMap.h (original) +++ lldb/trunk/include/lldb/Expression/ClangExpressionDeclMap.h Fri Sep 4 15:49:51 2015 @@ -387,9 +387,9 @@ public: CompilerDeclContext &namespace_decl, unsigned int current_id); private: -ClangExpressionVariableListm_found_entities; ///< All entities that were looked up for the parser. -ClangExpressionVariableListm_struct_members; ///< All entities that need to be placed in the struct. -bool m_keep_result_in_memory;///< True if result persistent variables generated by this expression should stay in memory. +ExpressionVariableList m_found_entities; ///< All entities that were looked up for the parser. +ExpressionVariableList m_struct_members; ///< All entities that need to be placed in the struct. +boolm_keep_result_in_memory;///< True if result persistent variables generated by this expression should stay in memory. //-- /// The following values should not live beyond parsing @@ -615,7 +615,7 @@ private: //-- void AddOneVariable (NameSearchContext &context, -lldb::ClangExpressionVariableSP &pvar_sp, +lldb::ExpressionVariableSP &pvar_sp, unsigned int current_id); //-- Modified: lldb/trunk/include/lldb/Expression/ClangFunction.h URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Expression/ClangFunction.h?rev=246871&r1=246870&r2=246871&view=diff ===
[Lldb-commits] [lldb] r246872 - I accidentally committed some project-file changes. Undid those.
Author: spyffe
Date: Fri Sep 4 15:54:25 2015
New Revision: 246872
URL: http://llvm.org/viewvc/llvm-project?rev=246872&view=rev
Log:
I accidentally committed some project-file changes. Undid those.
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
lldb/trunk/lldb.xcodeproj/xcshareddata/xcschemes/lldb-tool.xcscheme
Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=246872&r1=246871&r2=246872&view=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Fri Sep 4 15:54:25 2015
@@ -1393,7 +1393,7 @@
263E949D13661AE400E7D1CE /* UnwindAssembly-x86.cpp */ = {isa =
PBXFileReference; lastKnownFileType = sourcecode.cpp.cpp; path =
"UnwindAssembly-x86.cpp"; sourceTree = ""; };
263E949E13661AE400E7D1CE /* UnwindAssembly-x86.h */ = {isa =
PBXFileReference; lastKnownFileType = sourcecode.c.h; path =
"UnwindAssembly-x86.h"; sourceTree = ""; };
263FDE5D1A799F2D00E68013 /* FormatEntity.h */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name =
FormatEntity.h; path = include/lldb/Core/FormatEntity.h; sourceTree =
""; };
- 263FDE5F1A79A01500E68013 /* FormatEntity.cpp */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp;
lineEnding = 0; name = FormatEntity.cpp; path = source/Core/FormatEntity.cpp;
sourceTree = ""; xcLanguageSpecificationIdentifier = xcode.lang.cpp; };
+ 263FDE5F1A79A01500E68013 /* FormatEntity.cpp */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp;
name = FormatEntity.cpp; path = source/Core/FormatEntity.cpp; sourceTree =
""; };
263FEDA5112CC1DA00E4C208 /* ThreadSafeSTLMap.h */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name =
ThreadSafeSTLMap.h; path = include/lldb/Core/ThreadSafeSTLMap.h; sourceTree =
""; };
2640E19E15DC78FD00F23B50 /* Property.cpp */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp;
name = Property.cpp; path = source/Interpreter/Property.cpp; sourceTree =
""; };
26424E3C125986CB0016D82C /* ValueObjectConstResult.cpp */ =
{isa = PBXFileReference; fileEncoding = 4; lastKnownFileType =
sourcecode.cpp.cpp; name = ValueObjectConstResult.cpp; path =
source/Core/ValueObjectConstResult.cpp; sourceTree = ""; };
@@ -1920,7 +1920,7 @@
26BC7E1810F1B83100F91463 /* Watchpoint.cpp */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp;
name = Watchpoint.cpp; path = source/Breakpoint/Watchpoint.cpp; sourceTree =
""; };
26BC7E2D10F1B84700F91463 /* CommandObjectBreakpoint.cpp */ =
{isa = PBXFileReference; fileEncoding = 4; lastKnownFileType =
sourcecode.cpp.cpp; name = CommandObjectBreakpoint.cpp; path =
source/Commands/CommandObjectBreakpoint.cpp; sourceTree = ""; };
26BC7E3010F1B84700F91463 /* CommandObjectDisassemble.cpp */ =
{isa = PBXFileReference; fileEncoding = 4; lastKnownFileType =
sourcecode.cpp.cpp; name = CommandObjectDisassemble.cpp; path =
source/Commands/CommandObjectDisassemble.cpp; sourceTree = ""; };
- 26BC7E3110F1B84700F91463 /* CommandObjectExpression.cpp */ =
{isa = PBXFileReference; fileEncoding = 4; lastKnownFileType =
sourcecode.cpp.cpp; lineEnding = 0; name = CommandObjectExpression.cpp; path =
source/Commands/CommandObjectExpression.cpp; sourceTree = "";
xcLanguageSpecificationIdentifier = xcode.lang.cpp; };
+ 26BC7E3110F1B84700F91463 /* CommandObjectExpression.cpp */ =
{isa = PBXFileReference; fileEncoding = 4; lastKnownFileType =
sourcecode.cpp.cpp; name = CommandObjectExpression.cpp; path =
source/Commands/CommandObjectExpression.cpp; sourceTree = ""; };
26BC7E3310F1B84700F91463 /* CommandObjectHelp.cpp */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp;
name = CommandObjectHelp.cpp; path = source/Commands/CommandObjectHelp.cpp;
sourceTree = ""; };
26BC7E3610F1B84700F91463 /* CommandObjectMemory.cpp */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp;
name = CommandObjectMemory.cpp; path = source/Commands/CommandObjectMemory.cpp;
sourceTree = ""; };
26BC7E3810F1B84700F91463 /* CommandObjectProcess.cpp */ = {isa
= PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp;
name = CommandObjectProcess.cpp; path =
source/Commands/CommandObjectProcess.cpp; sourceTree = ""; };
@@ -1967,13 +1967,13 @@
26BC7E9610F1B85900F91463 /* Timer.cpp */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp;
name = Timer.cpp; path = source/
Re: [Lldb-commits] [Diffusion] rL246794: Roll dosep.py parallel test runner into dotest.py command line
I agree with Zachary that we shouldn't mess around with options piecemeal, but let Todd get done with this first round of fixes then go take a hatchet to the options that dotest has, hopefully removing all the ones that nobody needs and rationalizing the others. Jim > On Sep 4, 2015, at 1:31 PM, via lldb-commits > wrote: > > Understood. I don't think a short option for --output-on-success is needed > if -v turns it on. A short option for --test-subdir would be useful > however. Looks like these short options are still available: > BHIJKLMOQUVWYZjoz. > -z seems as good a choice as any :) ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [Diffusion] rL246794: Roll dosep.py parallel test runner into dotest.py command line
tfiala added a comment. I'm glad that worked for you, Dawn! Users: tfiala (Author) dawn (Auditor) http://reviews.llvm.org/rL246794 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r246873 - Move the C++ data formatters to the C++ language plugin
> On Sep 4, 2015, at 2:01 PM, Enrico Granata via lldb-commits > wrote: > > Added: >lldb/trunk/include/lldb/DataFormatters/CXXFunctionPointer.h > - copied unchanged from r246859, > lldb/trunk/include/lldb/DataFormatters/CXXFunctionPointer.h The Windows buildbot claims it can’t find this file, and hence fails to build I see the file in the commit log, and it also claims to be tracked on my local system, so I am not sure what is amiss here Can anyone with access to a Windows box please help look at it? Thanks, - Enrico 📩 egranata@.com ☎️ 27683 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r246876 - Never mind, I see what the problem is on the Windows build. Attempt a fix
Author: enrico Date: Fri Sep 4 16:22:54 2015 New Revision: 246876 URL: http://llvm.org/viewvc/llvm-project?rev=246876&view=rev Log: Never mind, I see what the problem is on the Windows build. Attempt a fix Modified: lldb/trunk/source/DataFormatters/CXXFunctionPointer.cpp lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp Modified: lldb/trunk/source/DataFormatters/CXXFunctionPointer.cpp URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/DataFormatters/CXXFunctionPointer.cpp?rev=246876&r1=246875&r2=246876&view=diff == --- lldb/trunk/source/DataFormatters/CXXFunctionPointer.cpp (original) +++ lldb/trunk/source/DataFormatters/CXXFunctionPointer.cpp Fri Sep 4 16:22:54 2015 @@ -7,7 +7,8 @@ // //===--===// -#include "CXXFunctionPointer.h" +#include "lldb/DataFormatters/CXXFunctionPointer.h" + #include "lldb/Target/SectionLoadList.h" #include "lldb/Target/Target.h" Modified: lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp?rev=246876&r1=246875&r2=246876&view=diff == --- lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp (original) +++ lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp Fri Sep 4 16:22:54 2015 @@ -20,7 +20,6 @@ #include "lldb/DataFormatters/DataVisualization.h" #include "lldb/DataFormatters/FormattersHelpers.h" -#include "CXXFunctionPointer.h" #include "CxxStringTypes.h" #include "LibCxx.h" #include "LibStdcpp.h" ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r246884 - Add a --language (-l) option to type category {enable|disable} to allow people to turn on and off formatters for a given language
Author: enrico
Date: Fri Sep 4 17:07:48 2015
New Revision: 246884
URL: http://llvm.org/viewvc/llvm-project?rev=246884&view=rev
Log:
Add a --language (-l) option to type category {enable|disable} to allow people
to turn on and off formatters for a given language
Modified:
lldb/trunk/include/lldb/DataFormatters/DataVisualization.h
lldb/trunk/include/lldb/DataFormatters/FormatManager.h
lldb/trunk/source/Commands/CommandObjectType.cpp
lldb/trunk/source/DataFormatters/DataVisualization.cpp
lldb/trunk/test/functionalities/type_completion/TestTypeCompletion.py
Modified: lldb/trunk/include/lldb/DataFormatters/DataVisualization.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/DataFormatters/DataVisualization.h?rev=246884&r1=246883&r2=246884&view=diff
==
--- lldb/trunk/include/lldb/DataFormatters/DataVisualization.h (original)
+++ lldb/trunk/include/lldb/DataFormatters/DataVisualization.h Fri Sep 4
17:07:48 2015
@@ -134,7 +134,13 @@ public:
TypeCategoryMap::Position = TypeCategoryMap::Default);
static void
+Enable (lldb::LanguageType lang_type);
+
+static void
Disable (const ConstString& category);
+
+static void
+Disable (lldb::LanguageType lang_type);
static void
Enable (const lldb::TypeCategoryImplSP& category,
Modified: lldb/trunk/include/lldb/DataFormatters/FormatManager.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/DataFormatters/FormatManager.h?rev=246884&r1=246883&r2=246884&view=diff
==
--- lldb/trunk/include/lldb/DataFormatters/FormatManager.h (original)
+++ lldb/trunk/include/lldb/DataFormatters/FormatManager.h Fri Sep 4 17:07:48
2015
@@ -258,6 +258,9 @@ public:
static ConstString
GetTypeForCache (ValueObject&, lldb::DynamicValueType);
+
+LanguageCategory*
+GetCategoryForLanguage (lldb::LanguageType lang_type);
private:
@@ -272,9 +275,6 @@ private:
bool did_strip_typedef,
bool root_level = false);
-LanguageCategory*
-GetCategoryForLanguage (lldb::LanguageType lang_type);
-
FormatCache m_format_cache;
NamedSummariesMap m_named_summaries_map;
std::atomic m_last_revision;
Modified: lldb/trunk/source/Commands/CommandObjectType.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectType.cpp?rev=246884&r1=246883&r2=246884&view=diff
==
--- lldb/trunk/source/Commands/CommandObjectType.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectType.cpp Fri Sep 4 17:07:48 2015
@@ -30,6 +30,7 @@
#include "lldb/Interpreter/CommandReturnObject.h"
#include "lldb/Interpreter/Options.h"
#include "lldb/Interpreter/OptionGroupFormat.h"
+#include "lldb/Target/Language.h"
#include "lldb/Target/Process.h"
#include "lldb/Target/StackFrame.h"
#include "lldb/Target/Target.h"
@@ -2460,12 +2461,79 @@ CommandObjectTypeSummaryList::CommandOpt
class CommandObjectTypeCategoryEnable : public CommandObjectParsed
{
+class CommandOptions : public Options
+{
+public:
+
+CommandOptions (CommandInterpreter &interpreter) :
+Options (interpreter)
+{
+}
+
+virtual
+~CommandOptions (){}
+
+virtual Error
+SetOptionValue (uint32_t option_idx, const char *option_arg)
+{
+Error error;
+const int short_option = m_getopt_table[option_idx].val;
+
+switch (short_option)
+{
+case 'l':
+if (option_arg)
+{
+m_language =
Language::GetLanguageTypeFromString(option_arg);
+if (m_language == lldb::eLanguageTypeUnknown)
+error.SetErrorStringWithFormat ("unrecognized
language '%s'", option_arg);
+}
+break;
+default:
+error.SetErrorStringWithFormat ("unrecognized option
'%c'", short_option);
+break;
+}
+
+return error;
+}
+
+void
+OptionParsingStarting ()
+{
+m_language = lldb::eLanguageTypeUnknown;
+}
+
+const OptionDefinition*
+GetDefinitions ()
+{
+return g_option_table;
+}
+
+// Options table: Required for subclasses of Options.
+
+static OptionDefinition g_option_table[];
+
+// Instance variables to hold the values for command options.
+
+lldb::LanguageType m_language;
+
+};
+
+
[Lldb-commits] [PATCH] D12651: Add ctrl-c support to parallel dotest.py.
tfiala created this revision.
tfiala added reviewers: clayborg, zturner.
tfiala added a subscriber: lldb-commits.
This change does the following:
* If Ctrl-C is hit once, the parallel dotest.py runner will stop any further
work from being started, but will wait for the existing tests in progress to
complete.
* If Ctrl-C is hit a second time, the parallel dotest.py will kill the process
trees for the child worker threads and the inferior dotest.py processes they
spawned.
In both cases, the report infrastructure is left intact to report on whatever
work was completed before it stopped. Thus, if 42 tests ran when the test was
keyboard interrupted, the results for those 42 tests will be displayed.
See https://llvm.org/bugs/show_bug.cgi?id=24709
http://reviews.llvm.org/D12651
Files:
test/dosep.py
Index: test/dosep.py
===
--- test/dosep.py
+++ test/dosep.py
@@ -36,8 +36,10 @@
import os
import fnmatch
import platform
+import Queue
import re
import dotest_args
+import signal
import subprocess
import sys
@@ -142,7 +144,7 @@
return passes, failures, unexpected_successes
-def call_with_timeout(command, timeout, name):
+def call_with_timeout(command, timeout, name, inferior_pid_events):
"""Run command with a timeout if possible."""
"""-s QUIT will create a coredump if they are enabled on your system"""
process = None
@@ -161,8 +163,12 @@
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
stderr=subprocess.PIPE)
+inferior_pid = process.pid
+inferior_pid_events.put_nowait(('created', inferior_pid))
output = process.communicate()
exit_status = process.returncode
+inferior_pid_events.put_nowait(('destroyed', inferior_pid))
+
passes, failures, unexpected_successes = parse_test_results(output)
if exit_status == 0:
# stdout does not have any useful information from 'dotest.py',
@@ -173,7 +179,7 @@
return name, exit_status, passes, failures, unexpected_successes
-def process_dir(root, files, test_root, dotest_argv):
+def process_dir(root, files, test_root, dotest_argv, inferior_pid_events):
"""Examine a directory for tests, and invoke any found within it."""
results = []
for name in files:
@@ -187,7 +193,8 @@
timeout = (os.getenv("LLDB_%s_TIMEOUT" % timeout_name) or
getDefaultTimeout(dotest_options.lldb_platform_name))
-results.append(call_with_timeout(command, timeout, name))
+results.append(call_with_timeout(
+command, timeout, name, inferior_pid_events))
# result = (name, status, passes, failures, unexpected_successes)
timed_out = [name for name, status, _, _, _ in results
@@ -208,10 +215,73 @@
out_q = None
-def process_dir_worker(arg_tuple):
+def process_dir_worker(a_output_lock, a_test_counter, a_total_tests,
+ a_test_name_len, a_dotest_options, job_queue,
+ result_queue, inferior_pid_events):
"""Worker thread main loop when in multithreaded mode.
Takes one directory specification at a time and works on it."""
-return process_dir(*arg_tuple)
+
+# Shut off interrupt handling in the child process.
+signal.signal(signal.SIGINT, signal.SIG_IGN)
+
+# Setup the global state for the worker process.
+setup_global_variables(
+a_output_lock, a_test_counter, a_total_tests, a_test_name_len,
+a_dotest_options)
+
+# Keep grabbing entries from the queue until done.
+while not job_queue.empty():
+try:
+job = job_queue.get(block=False)
+result = process_dir(job[0], job[1], job[2], job[3],
+ inferior_pid_events)
+result_queue.put(result)
+except Queue.Empty:
+# Fine, we're done.
+pass
+
+
+def collect_active_pids_from_pid_events(event_queue):
+"""
+Returns the set of what should be active inferior pids based on
+the event stream.
+
+@param event_queue a multiprocessing.Queue containing events of the
+form:
+ ('created', pid)
+ ('destroyed', pid)
+
+@return set of inferior dotest.py pids activated but never completed.
+"""
+active_pid_set = set()
+while not event_queue.empty():
+pid_event = event_queue.get_nowait()
+if pid_event[0] == 'created':
+active_pid_set.add(pid_event[1])
+elif pid_event[0] == 'destroyed':
+active_pid_set.remove(pid_event[1])
+return active_pid_set
+
+
+def kill_all_worker_processes(workers, inferior_pid_events):
+"""
+Kills all specified worker processes and their process tree.
+
+@param workers a list of multiprocess.Process worker objects.
+@param inferior_pid_events a multiprocess.Queue that contains
+all inferior create and destroy even
[Lldb-commits] [lldb] r246885 - Convert "long" input to "long long" in typemap for lldb::tid_t.
Author: sivachandra
Date: Fri Sep 4 17:26:52 2015
New Revision: 246885
URL: http://llvm.org/viewvc/llvm-project?rev=246885&view=rev
Log:
Convert "long" input to "long long" in typemap for lldb::tid_t.
Summary: lldb::tid_t is 64 bit, but "long" need not always be 64 bit.
Reviewers: chying, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12650
Modified:
lldb/trunk/scripts/Python/python-typemaps.swig
Modified: lldb/trunk/scripts/Python/python-typemaps.swig
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/Python/python-typemaps.swig?rev=246885&r1=246884&r2=246885&view=diff
==
--- lldb/trunk/scripts/Python/python-typemaps.swig (original)
+++ lldb/trunk/scripts/Python/python-typemaps.swig Fri Sep 4 17:26:52 2015
@@ -29,7 +29,7 @@
if (PyInt_Check($input))
$1 = PyInt_AsLong($input);
else if (PyLong_Check($input))
-$1 = PyLong_AsLong($input);
+$1 = PyLong_AsLongLong($input);
else
{
PyErr_SetString(PyExc_ValueError, "Expecting an integer");
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r246887 - Check for null compile unit so we don't crash.
Author: gclayton
Date: Fri Sep 4 17:29:46 2015
New Revision: 246887
URL: http://llvm.org/viewvc/llvm-project?rev=246887&view=rev
Log:
Check for null compile unit so we don't crash.
Modified:
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
Modified: lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp?rev=246887&r1=246886&r2=246887&view=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (original)
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp Fri Sep 4
17:29:46 2015
@@ -845,6 +845,9 @@ SymbolFileDWARF::DebugInfo() const
DWARFCompileUnit*
SymbolFileDWARF::GetDWARFCompileUnit(lldb_private::CompileUnit *comp_unit)
{
+if (!comp_unit)
+return nullptr;
+
DWARFDebugInfo* info = DebugInfo();
if (info)
{
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12651: Add ctrl-c support to parallel dotest.py.
zturner added a comment. Ctrl+C once doesn't work on Windows with this patch. It seems to continue starting up new processes, and after all of them are done, I'm left with the original set of Python processes not doing any work, just sitting there. If I Ctrl+C again everything does. Note that when I press the first Ctrl+C, I don't even get the print that says First Keyboard Interrupt received. http://reviews.llvm.org/D12651 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12651: Add ctrl-c support to parallel dotest.py.
clayborg accepted this revision. clayborg added a comment. This revision is now accepted and ready to land. Looks fine. Zach, do you need to make some modifications for Windows? Or should we just check this in and you can fix windows with a separate patch? http://reviews.llvm.org/D12651 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12651: Add ctrl-c support to parallel dotest.py.
I can try to put a little time into figuring out what's wrong. I'd rather it not go in broken though, so let me take a look first and we can figure out what to do after that. On Fri, Sep 4, 2015 at 3:35 PM Greg Clayton wrote: > clayborg accepted this revision. > clayborg added a comment. > This revision is now accepted and ready to land. > > Looks fine. Zach, do you need to make some modifications for Windows? Or > should we just check this in and you can fix windows with a separate patch? > > > http://reviews.llvm.org/D12651 > > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12651: Add ctrl-c support to parallel dotest.py.
tfiala added a comment. In http://reviews.llvm.org/D12651#240423, @zturner wrote: > Ctrl+C once doesn't work on Windows with this patch. It seems to continue > starting up new processes, and after all of them are done, I'm left with the > original set of Python processes not doing any work, just sitting there. If > I Ctrl+C again everything does. Okay. So its like the first Ctrl-C is essentially not even handled, but the second Ctrl-C does the nuclear option and kills everything. Is that right? > Note that when I press the first Ctrl+C, I don't even get the print that says > First Keyboard Interrupt received. That kinda sounds like these lines might be suspect: # Shut off interrupt handling in the child process. signal.signal(signal.SIGINT, signal.SIG_IGN) (at line 224-225). If they're not doing anything on Windows, then it is possible that the Ctrl-C could get gobbled by one of the child multiprocessing workers (?) I'll dig around and see if there's something different about how Windows handles disabling Ctrl-C. (If you know anything there, that'd be helpful as well). Worst case we could check os type and skip the soft kill on NT? http://reviews.llvm.org/D12651 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12651: Add ctrl-c support to parallel dotest.py.
tfiala added a comment. In http://reviews.llvm.org/D12651#240429, @zturner wrote: > I can try to put a little time into figuring out what's wrong. I'd rather > it not go in broken though, so let me take a look first and we can figure > out what to do after that. Yep absolutely. http://reviews.llvm.org/D12651 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12651: Add ctrl-c support to parallel dotest.py.
Hmm, yea the problem is worse than I thought. Even if I don't do Ctrl+C at all (I just run the test suite like I always have and let it finish) it's just leaving a bunch of stale processes at the end without them shutting down on their own. On Fri, Sep 4, 2015 at 3:39 PM Todd Fiala wrote: > tfiala added a comment. > > In http://reviews.llvm.org/D12651#240429, @zturner wrote: > > > I can try to put a little time into figuring out what's wrong. I'd > rather > > it not go in broken though, so let me take a look first and we can > figure > > out what to do after that. > > > Yep absolutely. > > > http://reviews.llvm.org/D12651 > > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12651: Add ctrl-c support to parallel dotest.py.
clayborg added a comment. I believe that python is also weird in that if you want to catch a CTRL+C it has to be executing python code (not in a python code the entered C/C++ code) otherwise the CTRL+C might not get to the python itself. This might be only a problem in the embedded python interpreter though so I could be wrong on this. http://reviews.llvm.org/D12651 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12651: Add ctrl-c support to parallel dotest.py.
clayborg added a comment. Were you running dosep.py on Windows before as the way to run your test suite? Or were you running dotest.py (no multi-threading)? http://reviews.llvm.org/D12651 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12651: Add ctrl-c support to parallel dotest.py.
tfiala added a comment. In http://reviews.llvm.org/D12651#240439, @zturner wrote: > Hmm, yea the problem is worse than I thought. Even if I don't do Ctrl+C at > all (I just run the test suite like I always have and let it finish) it's > just leaving a bunch of stale processes at the end without them shutting > down on their own. Ok, and it doesn't do that prior to the patch? (i.e. this isn't just a case of the processes slowly falling off at the end?) There's a point where all the worker processes are joined, which should mean they're done. So either the join is failing to complete (maybe because something in the process isn't wrapping up right), or the join isn't causing them to die. Is the initial test runner itself finishing up? http://reviews.llvm.org/D12651 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12651: Add ctrl-c support to parallel dotest.py.
Correct, it doesn't do that prior to the patch. It looks like it's never exiting this loop: try: for worker in workers: worker.join() except: either when a Ctrl+C happens, or when all the processes finish. I guess it's stuck in there for some reason. So even the test runner doesn't finish. Still investigating. Also to answer Greg's question, yes we were using dosep before. The problem seems to be related to swtiching from multiprocess.Pool to doing the pumping manually. On Fri, Sep 4, 2015 at 3:54 PM Todd Fiala wrote: > tfiala added a comment. > > In http://reviews.llvm.org/D12651#240439, @zturner wrote: > > > Hmm, yea the problem is worse than I thought. Even if I don't do Ctrl+C > at > > all (I just run the test suite like I always have and let it finish) > it's > > just leaving a bunch of stale processes at the end without them shutting > > down on their own. > > > Ok, and it doesn't do that prior to the patch? (i.e. this isn't just a > case of the processes slowly falling off at the end?) > > There's a point where all the worker processes are joined, which should > mean they're done. So either the join is failing to complete (maybe > because something in the process isn't wrapping up right), or the join > isn't causing them to die. > > Is the initial test runner itself finishing up? > > > http://reviews.llvm.org/D12651 > > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12651: Add ctrl-c support to parallel dotest.py.
tfiala added a comment. In http://reviews.llvm.org/D12651#240443, @zturner wrote: > Correct, it doesn't do that prior to the patch. It looks like it's never > exiting this loop: > > try: > for worker in workers: > worker.join() > except: > > > either when a Ctrl+C happens, or when all the processes finish. I guess > it's stuck in there for some reason. So even the test runner doesn't > finish. Still investigating. Okay let me go ahead and make a few changes that might help and resend the patch. Back in a few... http://reviews.llvm.org/D12651 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D12653: [TestMiBreak] Replace expectedFlakeyLinux with an appropriate expectedFailureAll
sivachandra created this revision.
sivachandra added a reviewer: chaoren.
sivachandra added a subscriber: lldb-commits.
http://reviews.llvm.org/D12653
Files:
test/tools/lldb-mi/breakpoint/TestMiBreak.py
Index: test/tools/lldb-mi/breakpoint/TestMiBreak.py
===
--- test/tools/lldb-mi/breakpoint/TestMiBreak.py
+++ test/tools/lldb-mi/breakpoint/TestMiBreak.py
@@ -13,7 +13,7 @@
@lldbmi_test
@skipIfWindows #llvm.org/pr24452: Get lldb-mi tests working on Windows
@skipIfFreeBSD # llvm.org/pr22411: Failure presumably due to known thread
races
-@expectedFlakeyLinux
+@expectedFailureAll("llvm.org/pr24717", oslist=["linux"],
compiler="clang", archs=["i386"])
def test_lldbmi_break_insert_function_pending(self):
"""Test that 'lldb-mi --interpreter' works for pending function
breakpoints."""
Index: test/tools/lldb-mi/breakpoint/TestMiBreak.py
===
--- test/tools/lldb-mi/breakpoint/TestMiBreak.py
+++ test/tools/lldb-mi/breakpoint/TestMiBreak.py
@@ -13,7 +13,7 @@
@lldbmi_test
@skipIfWindows #llvm.org/pr24452: Get lldb-mi tests working on Windows
@skipIfFreeBSD # llvm.org/pr22411: Failure presumably due to known thread races
-@expectedFlakeyLinux
+@expectedFailureAll("llvm.org/pr24717", oslist=["linux"], compiler="clang", archs=["i386"])
def test_lldbmi_break_insert_function_pending(self):
"""Test that 'lldb-mi --interpreter' works for pending function breakpoints."""
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r246894 - [TestMiBreak] Replace expectedFlakeyLinux with an appropriate expectedFailureAll
Author: sivachandra
Date: Fri Sep 4 18:11:38 2015
New Revision: 246894
URL: http://llvm.org/viewvc/llvm-project?rev=246894&view=rev
Log:
[TestMiBreak] Replace expectedFlakeyLinux with an appropriate expectedFailureAll
Reviewers: chaoren
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12653
Modified:
lldb/trunk/test/tools/lldb-mi/breakpoint/TestMiBreak.py
Modified: lldb/trunk/test/tools/lldb-mi/breakpoint/TestMiBreak.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/test/tools/lldb-mi/breakpoint/TestMiBreak.py?rev=246894&r1=246893&r2=246894&view=diff
==
--- lldb/trunk/test/tools/lldb-mi/breakpoint/TestMiBreak.py (original)
+++ lldb/trunk/test/tools/lldb-mi/breakpoint/TestMiBreak.py Fri Sep 4 18:11:38
2015
@@ -13,7 +13,7 @@ class MiBreakTestCase(lldbmi_testcase.Mi
@lldbmi_test
@skipIfWindows #llvm.org/pr24452: Get lldb-mi tests working on Windows
@skipIfFreeBSD # llvm.org/pr22411: Failure presumably due to known thread
races
-@expectedFlakeyLinux
+@expectedFailureAll("llvm.org/pr24717", oslist=["linux"],
compiler="clang", archs=["i386"])
def test_lldbmi_break_insert_function_pending(self):
"""Test that 'lldb-mi --interpreter' works for pending function
breakpoints."""
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D12654: Add missing include for va_list in MIUtilString.h
krytarowski created this revision. krytarowski added a reviewer: joerg. krytarowski added a subscriber: lldb-commits. krytarowski set the repository for this revision to rL LLVM. Problem was caught on NetBSD. Repository: rL LLVM http://reviews.llvm.org/D12654 Files: tools/lldb-mi/MIUtilString.h Index: tools/lldb-mi/MIUtilString.h === --- tools/lldb-mi/MIUtilString.h +++ tools/lldb-mi/MIUtilString.h @@ -13,6 +13,7 @@ #include #include #include +#include // In-house headers: #include "MIDataTypes.h" Index: tools/lldb-mi/MIUtilString.h === --- tools/lldb-mi/MIUtilString.h +++ tools/lldb-mi/MIUtilString.h @@ -13,6 +13,7 @@ #include #include #include +#include // In-house headers: #include "MIDataTypes.h" ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12651: Add ctrl-c support to parallel dotest.py.
tfiala updated this revision to Diff 34089.
tfiala added a comment.
Specify tight queue sizes for the job description queue and the job results
queue.
This *might* stop unintentional queue blocking when adding items to the queue
if they were sized too small by default. Might be a possible difference
between Windows and OS X/Linux.
http://reviews.llvm.org/D12651
Files:
test/dosep.py
Index: test/dosep.py
===
--- test/dosep.py
+++ test/dosep.py
@@ -36,8 +36,10 @@
import os
import fnmatch
import platform
+import Queue
import re
import dotest_args
+import signal
import subprocess
import sys
@@ -142,7 +144,7 @@
return passes, failures, unexpected_successes
-def call_with_timeout(command, timeout, name):
+def call_with_timeout(command, timeout, name, inferior_pid_events):
"""Run command with a timeout if possible."""
"""-s QUIT will create a coredump if they are enabled on your system"""
process = None
@@ -161,8 +163,12 @@
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
stderr=subprocess.PIPE)
+inferior_pid = process.pid
+inferior_pid_events.put_nowait(('created', inferior_pid))
output = process.communicate()
exit_status = process.returncode
+inferior_pid_events.put_nowait(('destroyed', inferior_pid))
+
passes, failures, unexpected_successes = parse_test_results(output)
if exit_status == 0:
# stdout does not have any useful information from 'dotest.py',
@@ -173,7 +179,7 @@
return name, exit_status, passes, failures, unexpected_successes
-def process_dir(root, files, test_root, dotest_argv):
+def process_dir(root, files, test_root, dotest_argv, inferior_pid_events):
"""Examine a directory for tests, and invoke any found within it."""
results = []
for name in files:
@@ -187,7 +193,8 @@
timeout = (os.getenv("LLDB_%s_TIMEOUT" % timeout_name) or
getDefaultTimeout(dotest_options.lldb_platform_name))
-results.append(call_with_timeout(command, timeout, name))
+results.append(call_with_timeout(
+command, timeout, name, inferior_pid_events))
# result = (name, status, passes, failures, unexpected_successes)
timed_out = [name for name, status, _, _, _ in results
@@ -208,10 +215,73 @@
out_q = None
-def process_dir_worker(arg_tuple):
+def process_dir_worker(a_output_lock, a_test_counter, a_total_tests,
+ a_test_name_len, a_dotest_options, job_queue,
+ result_queue, inferior_pid_events):
"""Worker thread main loop when in multithreaded mode.
Takes one directory specification at a time and works on it."""
-return process_dir(*arg_tuple)
+
+# Shut off interrupt handling in the child process.
+signal.signal(signal.SIGINT, signal.SIG_IGN)
+
+# Setup the global state for the worker process.
+setup_global_variables(
+a_output_lock, a_test_counter, a_total_tests, a_test_name_len,
+a_dotest_options)
+
+# Keep grabbing entries from the queue until done.
+while not job_queue.empty():
+try:
+job = job_queue.get(block=False)
+result = process_dir(job[0], job[1], job[2], job[3],
+ inferior_pid_events)
+result_queue.put(result)
+except Queue.Empty:
+# Fine, we're done.
+pass
+
+
+def collect_active_pids_from_pid_events(event_queue):
+"""
+Returns the set of what should be active inferior pids based on
+the event stream.
+
+@param event_queue a multiprocessing.Queue containing events of the
+form:
+ ('created', pid)
+ ('destroyed', pid)
+
+@return set of inferior dotest.py pids activated but never completed.
+"""
+active_pid_set = set()
+while not event_queue.empty():
+pid_event = event_queue.get_nowait()
+if pid_event[0] == 'created':
+active_pid_set.add(pid_event[1])
+elif pid_event[0] == 'destroyed':
+active_pid_set.remove(pid_event[1])
+return active_pid_set
+
+
+def kill_all_worker_processes(workers, inferior_pid_events):
+"""
+Kills all specified worker processes and their process tree.
+
+@param workers a list of multiprocess.Process worker objects.
+@param inferior_pid_events a multiprocess.Queue that contains
+all inferior create and destroy events. Used to construct
+the list of child pids still outstanding that need to be killed.
+"""
+for worker in workers:
+worker.terminate()
+worker.join()
+
+# Add all the child test pids created.
+active_pid_set = collect_active_pids_from_pid_events(
+inferior_pid_events)
+for inferior_pid in active_pid_set:
+print "killing inferior pid {}".format(inferior_pid)
+
Re: [Lldb-commits] [PATCH] D12651: Add ctrl-c support to parallel dotest.py.
tfiala added a comment. Hey Zachary, Can you give the latest patch a try? That might stop some unintentional blockage as adding items to those two queues would be blocking. I'm going to be relocating home in a minute, but the other thing I'm going to try is to go back to the multiprocessing.Pool() and see if the Ctrl-C woes that others hit are maybe somehow not an issue for us. If that's the case, then maybe the Pool() piece will take care of whatever isn't happy on the Windows side with the manual pooling. http://reviews.llvm.org/D12651 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12654: Add missing include for va_list in MIUtilString.h
krytarowski added a comment. Thank you. Please commit this change. Repository: rL LLVM http://reviews.llvm.org/D12654 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12651: Add ctrl-c support to parallel dotest.py.
Tried out this patch, unfortunately I'm seeing the same thing. The very first call to worker.join() is never returning. It's unfortunate that it's so hard to debug this stuff, do you have any suggestions for how I can try to nail down what the child dotest instance is actually doing? I wonder if it's blocking somewhere in its script, or if this is some quirk of the multiprocessing library's dynamic invocation / whatever magic is does. How much of an effort would it be to make the switch to threads now? The main thing we'd have to do is get rid of all of the globals in dotest, and make a DoTest class or something. As a last resort, you can bring back the pool.map logic behind an OS check, and use the multiprocess.Process logic for other platforms. But it would be great to have less platform specific branches and logic, not more. I'm willing to bet you could reproduce this on a Windows VM with a trash script that all it does is create some processes using the same structure of loop you're using here. Not sure if that's an option for you. I don't mind the back and forth diagnostics either, just whatever is easiest for you. On Fri, Sep 4, 2015 at 4:29 PM Todd Fiala wrote: > tfiala added a comment. > > Hey Zachary, > > Can you give the latest patch a try? That might stop some unintentional > blockage as adding items to those two queues would be blocking. > > I'm going to be relocating home in a minute, but the other thing I'm going > to try is to go back to the multiprocessing.Pool() and see if the Ctrl-C > woes that others hit are maybe somehow not an issue for us. If that's the > case, then maybe the Pool() piece will take care of whatever isn't happy on > the Windows side with the manual pooling. > > > http://reviews.llvm.org/D12651 > > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12651: Add ctrl-c support to parallel dotest.py.
tfiala added a comment. In http://reviews.llvm.org/D12651#240480, @zturner wrote: > Tried out this patch, unfortunately I'm seeing the same thing. The very > first call to worker.join() is never returning. > > It's unfortunate that it's so hard to debug this stuff, do you have any > suggestions for how I can try to nail down what the child dotest instance > is actually doing? I wonder if it's blocking somewhere in its script, or > if this is some quirk of the multiprocessing library's dynamic invocation / > whatever magic is does. > > How much of an effort would it be to make the switch to threads now? The > main thing we'd have to do is get rid of all of the globals in dotest, and > make a DoTest class or something. It's a bit more work than I want to take on right now. I think we really may want to keep the multiprocessing and just not exec out to dotest.py for a third-ish time for each inferior. > As a last resort, you can bring back the pool.map logic behind an OS check, > and use the multiprocess.Process logic for other platforms. But it would > be great to have less platform specific branches and logic, not more. > > I'm willing to bet you could reproduce this on a Windows VM with a trash > script that all it does is create some processes using the same structure > of loop you're using here. Not sure if that's an option for you. I don't > mind the back and forth diagnostics either, just whatever is easiest for > you. Yeah I will have to get a Windows LLDB setup going again. I've got one at home so I can try with that in the near future here. For the moment I'm going to throw up one with multiprocessing.Pool again and throw it over the wall after I make sure Ctrl-C is working with it here (OS X and Linux). I will try to get the Pool-based version going now. Back as soon as I have that! http://reviews.llvm.org/D12651 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12651: Add ctrl-c support to parallel dotest.py.
On Fri, Sep 4, 2015 at 5:10 PM Todd Fiala wrote: > tfiala added a comment. > > In http://reviews.llvm.org/D12651#240480, @zturner wrote: > > > Tried out this patch, unfortunately I'm seeing the same thing. The very > > first call to worker.join() is never returning. > > > > It's unfortunate that it's so hard to debug this stuff, do you have any > > suggestions for how I can try to nail down what the child dotest > instance > > is actually doing? I wonder if it's blocking somewhere in its script, > or > > if this is some quirk of the multiprocessing library's dynamic > invocation / > > whatever magic is does. > > > > How much of an effort would it be to make the switch to threads now? The > > main thing we'd have to do is get rid of all of the globals in dotest, > and > > make a DoTest class or something. > > > It's a bit more work than I want to take on right now. I think we really > may want to keep the multiprocessing and just not exec out to dotest.py for > a third-ish time for each inferior. > Just to clarify, are you saying we may want to keep multiprocessing over threads even if you can solve the exec problem? Any particular reason? Multi-threaded is much easier to debug, for starters, because you can just attach your debugger to a single process. It also solves a lot of race conditions and makes output processing easier (not to mention higher performance), because you don't even need a way to have the sub-processes communicate their results back to the parent because the results are just in memory. stick them in a synchronized queue and the parent can just process it. So it would probably even speed up the test runner. I think if there's not a very good reason to keep multiprocessing around, we should aim for a threaded approach. My understanding is that lit already does this, so there's no fundamental reason it shouldn't work correctly on MacOSX, just have to solve the exec problem like you mentioned. ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D12659: Use SI_KERNEL on platforms defining it
krytarowski created this revision.
krytarowski added a reviewer: joerg.
krytarowski added a subscriber: lldb-commits.
krytarowski set the repository for this revision to rL LLVM.
Herald added a subscriber: emaste.
Linux and FreeBSD occasionally send SI_KERNEL codes, nonexistent on other
platforms.
Problem caught on NetBSD.
Repository:
rL LLVM
http://reviews.llvm.org/D12659
Files:
source/Plugins/Process/POSIX/CrashReason.cpp
Index: source/Plugins/Process/POSIX/CrashReason.cpp
===
--- source/Plugins/Process/POSIX/CrashReason.cpp
+++ source/Plugins/Process/POSIX/CrashReason.cpp
@@ -28,11 +28,13 @@
switch (info.si_code)
{
+#ifdef SI_KERNEL
case SI_KERNEL:
// Linux will occasionally send spurious SI_KERNEL codes.
// (this is poorly documented in sigaction)
// One way to get this is via unaligned SIMD loads.
return CrashReason::eInvalidAddress; // for lack of anything better
+#endif
case SEGV_MAPERR:
return CrashReason::eInvalidAddress;
case SEGV_ACCERR:
Index: source/Plugins/Process/POSIX/CrashReason.cpp
===
--- source/Plugins/Process/POSIX/CrashReason.cpp
+++ source/Plugins/Process/POSIX/CrashReason.cpp
@@ -28,11 +28,13 @@
switch (info.si_code)
{
+#ifdef SI_KERNEL
case SI_KERNEL:
// Linux will occasionally send spurious SI_KERNEL codes.
// (this is poorly documented in sigaction)
// One way to get this is via unaligned SIMD loads.
return CrashReason::eInvalidAddress; // for lack of anything better
+#endif
case SEGV_MAPERR:
return CrashReason::eInvalidAddress;
case SEGV_ACCERR:
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D12651: Add ctrl-c support to parallel dotest.py.
On Fri, Sep 4, 2015 at 5:40 PM, Zachary Turner wrote: > > > On Fri, Sep 4, 2015 at 5:10 PM Todd Fiala wrote: > >> tfiala added a comment. >> >> In http://reviews.llvm.org/D12651#240480, @zturner wrote: >> >> > Tried out this patch, unfortunately I'm seeing the same thing. The very >> > first call to worker.join() is never returning. >> > >> > It's unfortunate that it's so hard to debug this stuff, do you have any >> > suggestions for how I can try to nail down what the child dotest >> instance >> > is actually doing? I wonder if it's blocking somewhere in its script, >> or >> > if this is some quirk of the multiprocessing library's dynamic >> invocation / >> > whatever magic is does. >> > >> > How much of an effort would it be to make the switch to threads now? >> The >> > main thing we'd have to do is get rid of all of the globals in dotest, >> and >> > make a DoTest class or something. >> >> >> It's a bit more work than I want to take on right now. I think we really >> may want to keep the multiprocessing and just not exec out to dotest.py for >> a third-ish time for each inferior. >> > > Just to clarify, are you saying we may want to keep multiprocessing over > threads even if you can solve the exec problem? Any particular reason? > Yes, you understood me correctly. Prior to me getting into it, dosep.py was designed to isolate each test into its own process (via the subprocess exec call) so that each test directory or file got its own lldb processor and there was process-level isolation, less contention on the Python global interpreter lock, etc. Then, when Steve Pucci and later I got to making it multithreaded, we wrapped the exec call in a "import threading" style thread pool. That maintained the process isolation property by having each thread just do an exec (i.e. multiple execs in parallel). Except, this didn't work on MacOSX. The exec calls grab the Python GIL on OS X (and not anywhere as as far as I could find). But multithreading + exec is a valid option for everything not OS X. The way I solved it to work for everyone was to drop the "import threading" approach and switch to the "import multiprocessing" approach. This worked everywhere, including on OS X (although with a few hiccups initially, as it exposed occasional hangs at the time with what looked like socket handling under Darwin). What I failed to see in my haste was that I then had two levels of fork/exec-like behavior (i.e. we had two process firewalls where we only needed one, at the cost of an extra exec): the multiprocessing works by effectively forking/creating a new process that is now isolated. But then we turn around and still create a subprocess to exec out to dotest.py. What I'm suggesting in the near future is if we stick with the multiprocessing approach, and eliminate the subprocess exec and instead just have the multiprocess worker call directly into a methodized entry point in dotest.py, we can skip the subprocess call within the multiprocess worker. It is already isolated and a separate process, so it is already fulfilling the isolation requirement. And it reduces the doubled processes created. And it works on OS X in addition to everywhere else. It does become more difficult to debug, but then again the majority of the logic is in dotest.py and can be debugged --no-multiprocess (or with logging). This is all separate somewhat from the Ctrl-C issue, but it is the backstory on what I'm referring to with the parallel test runner. Completely as an aside, I did ask Greg Clayton to see if he can poke into why OS X is hitting the Python GIL on execs in "import threading"-style execs from multiple threads. But assuming nothing magic changes there and it wasn't easily solved (I tried and failed after several attempts to diagnose last year), I'd prefer to keep a strategy that is the same unless there's a decent win on the execution front. That all said, I'm starting to think a pluggable strategy for the actual mechanic of the parallel test run might end up being best anyway since I'd really like the Ctrl-C working and I'm not able to diagnose what's happening on the Windows scenario. > Multi-threaded is much easier to debug, for starters, because you can > just attach your debugger to a single process. It also solves a lot of > race conditions and makes output processing easier (not to mention higher > performance), because you don't even need a way to have the sub-processes > communicate their results back to the parent because the results are just > in memory. stick them in a synchronized queue and the parent can just > process it. So it would probably even speed up the test runner. > > I think if there's not a very good reason to keep multiprocessing around, > we should aim for a threaded approach. My understanding is that lit > already does this, so there's no fundamental reason it shouldn't work > correctly on MacOSX, just have to solve the exec problem like you mentioned. > > > --
Re: [Lldb-commits] [PATCH] D12651: Add ctrl-c support to parallel dotest.py.
The pluggable method would at least allow everyone to continue working until someone has time to dig into what's wrong with multiprocess on Windows On Fri, Sep 4, 2015 at 9:56 PM Todd Fiala wrote: > On Fri, Sep 4, 2015 at 5:40 PM, Zachary Turner wrote: > >> >> >> On Fri, Sep 4, 2015 at 5:10 PM Todd Fiala wrote: >> >>> tfiala added a comment. >>> >>> In http://reviews.llvm.org/D12651#240480, @zturner wrote: >>> >>> > Tried out this patch, unfortunately I'm seeing the same thing. The >>> very >>> > first call to worker.join() is never returning. >>> > >>> > It's unfortunate that it's so hard to debug this stuff, do you have any >>> > suggestions for how I can try to nail down what the child dotest >>> instance >>> > is actually doing? I wonder if it's blocking somewhere in its >>> script, or >>> > if this is some quirk of the multiprocessing library's dynamic >>> invocation / >>> > whatever magic is does. >>> > >>> > How much of an effort would it be to make the switch to threads now? >>> The >>> > main thing we'd have to do is get rid of all of the globals in >>> dotest, and >>> > make a DoTest class or something. >>> >>> >>> It's a bit more work than I want to take on right now. I think we >>> really may want to keep the multiprocessing and just not exec out to >>> dotest.py for a third-ish time for each inferior. >>> >> >> Just to clarify, are you saying we may want to keep multiprocessing over >> threads even if you can solve the exec problem? Any particular reason? >> > > Yes, you understood me correctly. > > Prior to me getting into it, dosep.py was designed to isolate each test > into its own process (via the subprocess exec call) so that each test > directory or file got its own lldb processor and there was process-level > isolation, less contention on the Python global interpreter lock, etc. > > Then, when Steve Pucci and later I got to making it multithreaded, we > wrapped the exec call in a "import threading" style thread pool. That > maintained the process isolation property by having each thread just do an > exec (i.e. multiple execs in parallel). Except, this didn't work on > MacOSX. The exec calls grab the Python GIL on OS X (and not anywhere as as > far as I could find). But multithreading + exec is a valid option for > everything not OS X. > > The way I solved it to work for everyone was to drop the "import > threading" approach and switch to the "import multiprocessing" approach. > This worked everywhere, including on OS X (although with a few hiccups > initially, as it exposed occasional hangs at the time with what looked like > socket handling under Darwin). What I failed to see in my haste was that I > then had two levels of fork/exec-like behavior (i.e. we had two process > firewalls where we only needed one, at the cost of an extra exec): the > multiprocessing works by effectively forking/creating a new process that is > now isolated. But then we turn around and still create a subprocess to > exec out to dotest.py. > > What I'm suggesting in the near future is if we stick with the > multiprocessing approach, and eliminate the subprocess exec and instead > just have the multiprocess worker call directly into a methodized entry > point in dotest.py, we can skip the subprocess call within the multiprocess > worker. It is already isolated and a separate process, so it is already > fulfilling the isolation requirement. And it reduces the doubled processes > created. And it works on OS X in addition to everywhere else. It does > become more difficult to debug, but then again the majority of the logic is > in dotest.py and can be debugged --no-multiprocess (or with logging). > > This is all separate somewhat from the Ctrl-C issue, but it is the > backstory on what I'm referring to with the parallel test runner. > > Completely as an aside, I did ask Greg Clayton to see if he can poke into > why OS X is hitting the Python GIL on execs in "import threading"-style > execs from multiple threads. But assuming nothing magic changes there and > it wasn't easily solved (I tried and failed after several attempts to > diagnose last year), I'd prefer to keep a strategy that is the same unless > there's a decent win on the execution front. > > That all said, I'm starting to think a pluggable strategy for the actual > mechanic of the parallel test run might end up being best anyway since I'd > really like the Ctrl-C working and I'm not able to diagnose what's > happening on the Windows scenario. > > >> Multi-threaded is much easier to debug, for starters, because you can >> just attach your debugger to a single process. It also solves a lot of >> race conditions and makes output processing easier (not to mention higher >> performance), because you don't even need a way to have the sub-processes >> communicate their results back to the parent because the results are just >> in memory. stick them in a synchronized queue and the parent can just >> process it. So it would probab
Re: [Lldb-commits] [PATCH] D12651: Add ctrl-c support to parallel dotest.py.
Yep, I'm thinking that's right. On Fri, Sep 4, 2015 at 10:02 PM, Zachary Turner wrote: > The pluggable method would at least allow everyone to continue working > until someone has time to dig into what's wrong with multiprocess on Windows > > On Fri, Sep 4, 2015 at 9:56 PM Todd Fiala wrote: > >> On Fri, Sep 4, 2015 at 5:40 PM, Zachary Turner >> wrote: >> >>> >>> >>> On Fri, Sep 4, 2015 at 5:10 PM Todd Fiala wrote: >>> tfiala added a comment. In http://reviews.llvm.org/D12651#240480, @zturner wrote: > Tried out this patch, unfortunately I'm seeing the same thing. The very > first call to worker.join() is never returning. > > It's unfortunate that it's so hard to debug this stuff, do you have any > suggestions for how I can try to nail down what the child dotest instance > is actually doing? I wonder if it's blocking somewhere in its script, or > if this is some quirk of the multiprocessing library's dynamic invocation / > whatever magic is does. > > How much of an effort would it be to make the switch to threads now? The > main thing we'd have to do is get rid of all of the globals in dotest, and > make a DoTest class or something. It's a bit more work than I want to take on right now. I think we really may want to keep the multiprocessing and just not exec out to dotest.py for a third-ish time for each inferior. >>> >>> Just to clarify, are you saying we may want to keep multiprocessing over >>> threads even if you can solve the exec problem? Any particular reason? >>> >> >> Yes, you understood me correctly. >> >> Prior to me getting into it, dosep.py was designed to isolate each test >> into its own process (via the subprocess exec call) so that each test >> directory or file got its own lldb processor and there was process-level >> isolation, less contention on the Python global interpreter lock, etc. >> >> Then, when Steve Pucci and later I got to making it multithreaded, we >> wrapped the exec call in a "import threading" style thread pool. That >> maintained the process isolation property by having each thread just do an >> exec (i.e. multiple execs in parallel). Except, this didn't work on >> MacOSX. The exec calls grab the Python GIL on OS X (and not anywhere as as >> far as I could find). But multithreading + exec is a valid option for >> everything not OS X. >> >> The way I solved it to work for everyone was to drop the "import >> threading" approach and switch to the "import multiprocessing" approach. >> This worked everywhere, including on OS X (although with a few hiccups >> initially, as it exposed occasional hangs at the time with what looked like >> socket handling under Darwin). What I failed to see in my haste was that I >> then had two levels of fork/exec-like behavior (i.e. we had two process >> firewalls where we only needed one, at the cost of an extra exec): the >> multiprocessing works by effectively forking/creating a new process that is >> now isolated. But then we turn around and still create a subprocess to >> exec out to dotest.py. >> >> What I'm suggesting in the near future is if we stick with the >> multiprocessing approach, and eliminate the subprocess exec and instead >> just have the multiprocess worker call directly into a methodized entry >> point in dotest.py, we can skip the subprocess call within the multiprocess >> worker. It is already isolated and a separate process, so it is already >> fulfilling the isolation requirement. And it reduces the doubled processes >> created. And it works on OS X in addition to everywhere else. It does >> become more difficult to debug, but then again the majority of the logic is >> in dotest.py and can be debugged --no-multiprocess (or with logging). >> >> This is all separate somewhat from the Ctrl-C issue, but it is the >> backstory on what I'm referring to with the parallel test runner. >> >> Completely as an aside, I did ask Greg Clayton to see if he can poke into >> why OS X is hitting the Python GIL on execs in "import threading"-style >> execs from multiple threads. But assuming nothing magic changes there and >> it wasn't easily solved (I tried and failed after several attempts to >> diagnose last year), I'd prefer to keep a strategy that is the same unless >> there's a decent win on the execution front. >> >> That all said, I'm starting to think a pluggable strategy for the actual >> mechanic of the parallel test run might end up being best anyway since I'd >> really like the Ctrl-C working and I'm not able to diagnose what's >> happening on the Windows scenario. >> >> >>> Multi-threaded is much easier to debug, for starters, because you can >>> just attach your debugger to a single process. It also solves a lot of >>> race conditions and makes output processing easier (not to mention higher >>> performance), because you don't even need a way to have th
Re: [Lldb-commits] [PATCH] D12651: Add ctrl-c support to parallel dotest.py.
That'll also let me set it up so Greg can poke around with the threading version on OS X. On Fri, Sep 4, 2015 at 10:04 PM, Todd Fiala wrote: > Yep, I'm thinking that's right. > > On Fri, Sep 4, 2015 at 10:02 PM, Zachary Turner > wrote: > >> The pluggable method would at least allow everyone to continue working >> until someone has time to dig into what's wrong with multiprocess on Windows >> >> On Fri, Sep 4, 2015 at 9:56 PM Todd Fiala wrote: >> >>> On Fri, Sep 4, 2015 at 5:40 PM, Zachary Turner >>> wrote: >>> On Fri, Sep 4, 2015 at 5:10 PM Todd Fiala wrote: > tfiala added a comment. > > In http://reviews.llvm.org/D12651#240480, @zturner wrote: > > > Tried out this patch, unfortunately I'm seeing the same thing. The > very > > first call to worker.join() is never returning. > > > > It's unfortunate that it's so hard to debug this stuff, do you have > any > > suggestions for how I can try to nail down what the child dotest > instance > > is actually doing? I wonder if it's blocking somewhere in its > script, or > > if this is some quirk of the multiprocessing library's dynamic > invocation / > > whatever magic is does. > > > > How much of an effort would it be to make the switch to threads > now? The > > main thing we'd have to do is get rid of all of the globals in > dotest, and > > make a DoTest class or something. > > > It's a bit more work than I want to take on right now. I think we > really may want to keep the multiprocessing and just not exec out to > dotest.py for a third-ish time for each inferior. > Just to clarify, are you saying we may want to keep multiprocessing over threads even if you can solve the exec problem? Any particular reason? >>> >>> Yes, you understood me correctly. >>> >>> Prior to me getting into it, dosep.py was designed to isolate each test >>> into its own process (via the subprocess exec call) so that each test >>> directory or file got its own lldb processor and there was process-level >>> isolation, less contention on the Python global interpreter lock, etc. >>> >>> Then, when Steve Pucci and later I got to making it multithreaded, we >>> wrapped the exec call in a "import threading" style thread pool. That >>> maintained the process isolation property by having each thread just do an >>> exec (i.e. multiple execs in parallel). Except, this didn't work on >>> MacOSX. The exec calls grab the Python GIL on OS X (and not anywhere as as >>> far as I could find). But multithreading + exec is a valid option for >>> everything not OS X. >>> >>> The way I solved it to work for everyone was to drop the "import >>> threading" approach and switch to the "import multiprocessing" approach. >>> This worked everywhere, including on OS X (although with a few hiccups >>> initially, as it exposed occasional hangs at the time with what looked like >>> socket handling under Darwin). What I failed to see in my haste was that I >>> then had two levels of fork/exec-like behavior (i.e. we had two process >>> firewalls where we only needed one, at the cost of an extra exec): the >>> multiprocessing works by effectively forking/creating a new process that is >>> now isolated. But then we turn around and still create a subprocess to >>> exec out to dotest.py. >>> >>> What I'm suggesting in the near future is if we stick with the >>> multiprocessing approach, and eliminate the subprocess exec and instead >>> just have the multiprocess worker call directly into a methodized entry >>> point in dotest.py, we can skip the subprocess call within the multiprocess >>> worker. It is already isolated and a separate process, so it is already >>> fulfilling the isolation requirement. And it reduces the doubled processes >>> created. And it works on OS X in addition to everywhere else. It does >>> become more difficult to debug, but then again the majority of the logic is >>> in dotest.py and can be debugged --no-multiprocess (or with logging). >>> >>> This is all separate somewhat from the Ctrl-C issue, but it is the >>> backstory on what I'm referring to with the parallel test runner. >>> >>> Completely as an aside, I did ask Greg Clayton to see if he can poke >>> into why OS X is hitting the Python GIL on execs in "import >>> threading"-style execs from multiple threads. But assuming nothing magic >>> changes there and it wasn't easily solved (I tried and failed after several >>> attempts to diagnose last year), I'd prefer to keep a strategy that is the >>> same unless there's a decent win on the execution front. >>> >>> That all said, I'm starting to think a pluggable strategy for the actual >>> mechanic of the parallel test run might end up being best anyway since I'd >>> really like the Ctrl-C working and I'm not able to diagnose what's >>> happening on the Windows scenario. >>> >>> Multi-threaded is much easie
