Re: [Lldb-commits] [PATCH] D21280: Allow installing watchpoints at less than 8-byte alligned addresses for AArch64 targets
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
Thanks for adding the test. I have some nits about some details of the test. If
you agree with them, you can commit the updated version without additional
review.
Comment at:
packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_size/TestWatchpointSizes.py:2
@@ +1,3 @@
+"""
+Test watchpoint size cases (1-byte, 2-byte, 4-byte or 8-byte).
+"""
Add: "Also make sure that the watchpoints work when the variables are not
placed at 8-byte aligned addresses." or something to that effect. Otherwise,
someone in the future will wonder why the test is so complicated.
Also, you don't seem to test 8-byte watchpoints (which is fine, but the comment
is not correct then).
Comment at:
packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_size/TestWatchpointSizes.py:15
@@ +14,3 @@
+
+mydir = TestBase.compute_mydir(__file__)
+
How about adding NO_DEBUG_INFO_TESTCASE = True here? We are not testing debug
info, so it should be enough to run the test once.
Comment at:
packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_size/TestWatchpointSizes.py:49
@@ +48,3 @@
+
+def run_watchpoint_size_test(self, arrayName, rangelimit, wsize):
+self.build(dictionary=self.d)
this would a lot more natural if you renamed this into `array_size` or
something and used 0-based indexes.
Comment at:
packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_size/TestWatchpointSizes.py:66
@@ +65,3 @@
+
+for i in range(1,rangelimit):
+# We should be stopped again due to the breakpoint.
`range(array_size)`
Comment at:
packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_size/TestWatchpointSizes.py:73
@@ +72,3 @@
+# Set a read_write type watchpoint arrayName
+watch_loc=arrayName+"[" + str(i-1) + "]"
+self.expect("watchpoint set variable -w read_write " + watch_loc,
`str(i)`
Comment at:
packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_size/TestWatchpointSizes.py:104
@@ +103,3 @@
+self.expect("watchpoint list -v",
+substrs = ['hit_count = 2'])
+
I guess the intention here is to test both read and write watchpoints. If so,
could you state that somewhere (in a comment at least, if it's possible to
somehow verify the watchpoint type in code, even better).
Comment at:
packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_size/main.c:46
@@ +45,3 @@
+pad1++;
+localWord = wordArray[i]; // Here onwards we should'nt be stopped in
loop
+wordArray[i]++;
shouldn't (typo)
http://reviews.llvm.org/D21280
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D21280: Allow installing watchpoints at less than 8-byte alligned addresses for AArch64 targets
omjavaid updated this revision to Diff 60942.
omjavaid added a comment.
Herald added a subscriber: srhines.
I have added a test cases that tests all possibilities supported by current
configuration.
Tests pass on Nexus 9 and aarch64-linux-gnu (hikey board).
LGTM?
http://reviews.llvm.org/D21280
Files:
packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_size/Makefile
packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_size/TestWatchpointSizes.py
packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_size/main.c
source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
Index: source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -2059,7 +2059,8 @@
{
WatchpointSP wp_sp;
ArchSpec::Core core = GetTarget().GetArchitecture().GetCore();
-if (core >= ArchSpec::kCore_mips_first && core <= ArchSpec::kCore_mips_last)
+if ((core >= ArchSpec::kCore_mips_first && core <= ArchSpec::kCore_mips_last) ||
+(core >= ArchSpec::eCore_arm_arm64 && core <= ArchSpec::eCore_arm_aarch64))
wp_sp = GetTarget().GetWatchpointList().FindByAddress(wp_hit_addr);
if (!wp_sp)
wp_sp = GetTarget().GetWatchpointList().FindByAddress(wp_addr);
Index: source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
===
--- source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
+++ source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
@@ -74,6 +74,9 @@
GetWatchpointHitIndex(uint32_t &wp_index, lldb::addr_t trap_addr) override;
lldb::addr_t
+GetWatchpointHitAddress (uint32_t wp_index) override;
+
+lldb::addr_t
GetWatchpointAddress (uint32_t wp_index) override;
uint32_t
@@ -161,6 +164,8 @@
struct DREG
{
lldb::addr_t address; // Breakpoint/watchpoint address value.
+lldb::addr_t hit_addr; // Address at which last watchpoint trigger exception occurred.
+lldb::addr_t real_addr; // Address value that should cause target to stop.
uint32_t control; // Breakpoint/watchpoint control value.
uint32_t refcount; // Serves as enable/disable and refernce counter.
};
Index: source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
===
--- source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
+++ source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
@@ -566,6 +566,7 @@
return LLDB_INVALID_INDEX32;
uint32_t control_value = 0, wp_index = 0;
+lldb::addr_t real_addr = addr;
// Check if we are setting watchpoint other than read/write/access
// Also update watchpoint flag to match AArch64 write-read bit configuration.
@@ -588,9 +589,23 @@
return LLDB_INVALID_INDEX32;
// Check 8-byte alignment for hardware watchpoint target address.
-// TODO: Add support for watching un-aligned addresses
+// Below is a hack to recalculate address and size in order to
+// make sure we can watch non 8-byte alligned addresses as well.
if (addr & 0x07)
-return LLDB_INVALID_INDEX32;
+{
+uint8_t watch_mask = (addr & 0x07) + size;
+
+if (watch_mask > 0x08)
+return LLDB_INVALID_INDEX32;
+else if (watch_mask <= 0x02)
+size = 2;
+else if (watch_mask <= 0x04)
+size = 4;
+else
+size = 8;
+
+addr = addr & (~0x07);
+}
// Setup control value
control_value = watch_flags << 3;
@@ -620,6 +635,7 @@
if ((m_hwp_regs[wp_index].control & 1) == 0)
{
// Update watchpoint in local cache
+m_hwp_regs[wp_index].real_addr = real_addr;
m_hwp_regs[wp_index].address = addr;
m_hwp_regs[wp_index].control = control_value;
m_hwp_regs[wp_index].refcount = 1;
@@ -801,6 +817,7 @@
if (m_hwp_regs[wp_index].refcount >= 1 && WatchpointIsEnabled(wp_index)
&& trap_addr >= watch_addr && trap_addr < watch_addr + watch_size)
{
+m_hwp_regs[wp_index].hit_addr = trap_addr;
return Error();
}
}
@@ -821,7 +838,24 @@
return LLDB_INVALID_ADDRESS;
if (WatchpointIsEnabled(wp_index))
-return m_hwp_regs[wp_index].address
[Lldb-commits] [PATCH] D21422: Fix typo in eOpenOptionDontFollowSymlinks
fjricci created this revision. fjricci added reviewers: clayborg, labath. fjricci added a subscriber: lldb-commits. Fix capitalization http://reviews.llvm.org/D21422 Files: include/lldb/Host/File.h source/Host/common/File.cpp source/Target/Platform.cpp Index: source/Target/Platform.cpp === --- source/Target/Platform.cpp +++ source/Target/Platform.cpp @@ -1431,7 +1431,7 @@ uint32_t source_open_options = File::eOpenOptionRead | File::eOpenOptionCloseOnExec; if (source.GetFileType() == FileSpec::eFileTypeSymbolicLink) -source_open_options |= File::eOpenoptionDontFollowSymlinks; +source_open_options |= File::eOpenOptionDontFollowSymlinks; File source_file(source, source_open_options, lldb::eFilePermissionsUserRW); Error error; Index: source/Host/common/File.cpp === --- source/Host/common/File.cpp +++ source/Host/common/File.cpp @@ -238,7 +238,7 @@ oflag |= O_RDONLY; #ifndef _WIN32 -if (options & eOpenoptionDontFollowSymlinks) +if (options & eOpenOptionDontFollowSymlinks) oflag |= O_NOFOLLOW; #endif } Index: include/lldb/Host/File.h === --- include/lldb/Host/File.h +++ include/lldb/Host/File.h @@ -45,7 +45,7 @@ eOpenOptionNonBlocking = (1u << 4),// File reads eOpenOptionCanCreate= (1u << 5),// Create file if doesn't already exist eOpenOptionCanCreateNewOnly = (1u << 6),// Can create file only if it doesn't already exist -eOpenoptionDontFollowSymlinks = (1u << 7), +eOpenOptionDontFollowSymlinks = (1u << 7), eOpenOptionCloseOnExec = (1u << 8) // Close the file when executing a new process }; Index: source/Target/Platform.cpp === --- source/Target/Platform.cpp +++ source/Target/Platform.cpp @@ -1431,7 +1431,7 @@ uint32_t source_open_options = File::eOpenOptionRead | File::eOpenOptionCloseOnExec; if (source.GetFileType() == FileSpec::eFileTypeSymbolicLink) -source_open_options |= File::eOpenoptionDontFollowSymlinks; +source_open_options |= File::eOpenOptionDontFollowSymlinks; File source_file(source, source_open_options, lldb::eFilePermissionsUserRW); Error error; Index: source/Host/common/File.cpp === --- source/Host/common/File.cpp +++ source/Host/common/File.cpp @@ -238,7 +238,7 @@ oflag |= O_RDONLY; #ifndef _WIN32 -if (options & eOpenoptionDontFollowSymlinks) +if (options & eOpenOptionDontFollowSymlinks) oflag |= O_NOFOLLOW; #endif } Index: include/lldb/Host/File.h === --- include/lldb/Host/File.h +++ include/lldb/Host/File.h @@ -45,7 +45,7 @@ eOpenOptionNonBlocking = (1u << 4),// File reads eOpenOptionCanCreate= (1u << 5),// Create file if doesn't already exist eOpenOptionCanCreateNewOnly = (1u << 6),// Can create file only if it doesn't already exist -eOpenoptionDontFollowSymlinks = (1u << 7), +eOpenOptionDontFollowSymlinks = (1u << 7), eOpenOptionCloseOnExec = (1u << 8) // Close the file when executing a new process }; ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r272844 - Set TERM env var for Xcode gtests
Author: tfiala
Date: Wed Jun 15 16:31:02 2016
New Revision: 272844
URL: http://llvm.org/viewvc/llvm-project?rev=272844&view=rev
Log:
Set TERM env var for Xcode gtests
Not sure what changed, but something outside our code
is failing one of the EditLine gtests on OS X CI (and
locally) before the gtest ever gets to run. This fails
the first EditLine gtest.
This change exports the TERM as "vt100" before running
the lldb-gtest binary, fixing the issue.
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=272844&r1=272843&r2=272844&view=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Wed Jun 15 16:31:02 2016
@@ -6336,7 +6336,7 @@
);
runOnlyForDeploymentPostprocessing = 0;
shellPath = /bin/sh;
- shellScript = "# Run the just-built gtest
executable\n\n# Uncomment this to see the steps in action\n# set -x\n\n# We
need to hide the lldb.py that goes into BUILT_PRODUCTS\n# because it will
conflict with finding the lldb module later,\n# which causes the python
exception tests to fail.\nif [ -f \"${BUILT_PRODUCTS_DIR}/lldb.py\" ]; then\n
mv -f \"${BUILT_PRODUCTS_DIR}/lldb.py\"
\"${BUILT_PRODUCTS_DIR}/park.lldb.py\"\nfi\n\n# Tell lldb-gtest where to find
the lldb package\nexport
PYTHONPATH=${BUILT_PRODUCTS_DIR}/LLDB.framework/Resources/Python\n\n# We must
redirect stdin to /dev/null: without this, xcodebuild\n# will wait forever for
input when we run the TestExceptionStateChecking\n#
test.\n${BUILT_PRODUCTS_DIR}/lldb-gtest
--gtest_output=xml:${BUILD_DIR}/gtest-results.xml < /dev/null\nRETCODE=$?\n\nif
[ -f \"${BUILT_PRODUCTS_DIR}/park.lldb.py\" ]; then\nmv -f
\"${BUILT_PRODUCTS_DIR}/park.lldb.py\"
\"${BUILT_PRODUCTS_DIR}/lldb.py\"\nfi\n\nexit ${RETCODE}";
+ shellScript = "# Run the just-built gtest
executable\n\n# Uncomment this to see the steps in action\n# set -x\n\n# We
need to hide the lldb.py that goes into BUILT_PRODUCTS\n# because it will
conflict with finding the lldb module later,\n# which causes the python
exception tests to fail.\nif [ -f \"${BUILT_PRODUCTS_DIR}/lldb.py\" ]; then\n
mv -f \"${BUILT_PRODUCTS_DIR}/lldb.py\"
\"${BUILT_PRODUCTS_DIR}/park.lldb.py\"\nfi\n\n# Tell lldb-gtest where to find
the lldb package\nexport
PYTHONPATH=${BUILT_PRODUCTS_DIR}/LLDB.framework/Resources/Python\n\n# Set the
terminal to VT100 so that the editline internals don't\n# fail.\nexport
TERM=vt100\n\n# We must redirect stdin to /dev/null: without this,
xcodebuild\n# will wait forever for input when we run the
TestExceptionStateChecking\n# test.\n${BUILT_PRODUCTS_DIR}/lldb-gtest
--gtest_output=xml:${BUILD_DIR}/gtest-results.xml < /dev/null\nRETCODE=$?\n\nif
[ -f \"${BUILT_PRODUCTS_DIR}/park.lldb.py\" ]; then\nmv -f
\"${BUILT_PRODUCTS_DIR
}/park.lldb.py\" \"${BUILT_PRODUCTS_DIR}/lldb.py\"\nfi\n\nexit ${RETCODE}";
};
261B5A7511C3FA6F00AABD0A /* Fixup Framework Headers */ = {
isa = PBXShellScriptBuildPhase;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] Buildbot numbers for the last week of 6/05/2016 - 6/11/2016
Maybe a comma-separated attachments? The tables relay positioning and font. Thanks Galina On Tue, Jun 14, 2016 at 6:59 PM, Sean Silva wrote: > Some of these tables are getting quite mangled somewhere along the line > (email client? mailing list handling? idk). Could you re-send with the > tables also attached or something else that avoids that problem? > > -- Sean Silva > > > On Tue, Jun 14, 2016 at 4:23 PM, Galina Kistanova via cfe-commits < > cfe-comm...@lists.llvm.org> wrote: > >> Hello everyone, >> >> Below are some buildbot numbers for the last week of 6/05/2016 - >> 6/11/2016. >> >> Thanks >> >> Galina >> >> >> >> buildername | was_red >> ---+--- >> sanitizer-x86_64-linux-bootstrap | 134:12:25 >> perf-x86_64-penryn-O3-polly-parallel-fast | 46:29:26 >> llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast| 37:56:11 >> polly-amd64-linux | 34:53:03 >> sanitizer-x86_64-linux-fuzzer | 30:17:25 >> clang-x64-ninja-win7 | 25:37:00 >> llvm-clang-lld-x86_64-debian-fast | 25:32:54 >> clang-cmake-thumbv7-a15-full-sh | 25:31:44 >> clang-x86-win2008-selfhost| 25:25:42 >> clang-atom-d525-fedora-rel| 24:52:25 >> sanitizer-x86_64-linux| 24:21:15 >> clang-ppc64be-linux-lnt | 24:19:40 >> clang-ppc64be-linux | 24:02:53 >> sanitizer-ppc64le-linux | 22:44:45 >> lldb-windows7-android | 20:42:45 >> sanitizer-ppc64be-linux | 19:49:26 >> llvm-sphinx-docs | 19:44:43 >> clang-s390x-linux | 17:18:07 >> clang-cmake-mips | 16:39:48 >> perf-x86_64-penryn-O3 | 16:32:12 >> clang-cuda-build | 12:52:45 >> llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast | 11:58:08 >> perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only | 11:23:05 >> clang-ppc64le-linux | 10:55:20 >> perf-x86_64-penryn-O3-polly | 10:09:52 >> libcxx-libcxxabi-x86_64-linux-debian | 06:31:45 >> clang-cmake-armv7-a15-selfhost| 04:54:20 >> clang-ppc64le-linux-multistage| 04:39:08 >> clang-cmake-mipsel| 04:07:57 >> lldb-x86_64-darwin-13.4 | 04:07:15 >> clang-native-arm-lnt | 04:02:19 >> lld-x86_64-win7 | 04:01:13 >> clang-cmake-aarch64-full | 03:44:15 >> clang-cmake-armv7-a15-full| 03:39:18 >> clang-cmake-armv7-a15 | 03:28:48 >> clang-cmake-thumbv7-a15 | 03:28:06 >> libcxx-libcxxabi-arm-linux| 03:19:42 >> clang-ppc64le-linux-lnt | 03:17:11 >> clang-x86_64-linux-selfhost-modules | 02:58:31 >> clang-cmake-aarch64-quick | 02:39:58 >> libcxx-libcxxabi-x86_64-linux-ubuntu-unstable-abi | 02:25:49 >> libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11 | 02:25:33 >> libcxx-libcxxabi-x86_64-linux-ubuntu-msan | 02:22:56 >> llvm-mips-linux | 02:22:54 >> libcxx-libcxxabi-x86_64-linux-ubuntu-tsan | 02:22:39 >> libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03| 02:19:56 >> libcxx-libcxxabi-x86_64-linux-ubuntu-asan | 02:19:30 >> libcxx-libcxxabi-x86_64-linux-ubuntu-cxx1z| 02:17:10 >> libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14| 02:14:04 >> libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11| 02:13:58 >> libcxx-libcxxabi-libunwind-x86_64-linux-ubuntu| 02:13:27 >> lldb-x86_64-ubuntu-14.04-android | 02:10:25 >> lldb-x86_64-ubuntu-14.04-buildserver | 02:02:39 >> clang-x86_64-debian-fast | 01:52:47 >> sanitizer-x86_64-linux-fast | 01:41:33 >> lldb-amd64-ninja-netbsd7 | 01:36:27 >> perf-x86_64-penryn-O3-polly-unprofitable | 01:33:54 >> clang-x86_64-linux-abi-test
Re: [Lldb-commits] [PATCH] D17027: [expression evaluator] Allow runtimes to execute custom LLVM ModulePasses over the generated IR at various stages after expression compilation.
ldrumm abandoned this revision. ldrumm added a comment. committed in http://reviews.llvm.org/rL272800 http://reviews.llvm.org/D17027 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r272800 - Allow runtimes to execute custom LLVM ModulePasses over the expression IR
Author: ldrumm
Date: Wed Jun 15 11:19:46 2016
New Revision: 272800
URL: http://llvm.org/viewvc/llvm-project?rev=272800&view=rev
Log:
Allow runtimes to execute custom LLVM ModulePasses over the expression IR
During expression evaluation, the ClangExpressionParser preforms a
number of hard-coded fixups on the expression's IR before the module
is assembled and dispatched to be run in a ThreadPlan.
This patch allows the runtimes to register LLVM passes to be run over the
generated IR, that they may perform language or architecture-specfic fixups
or analyses over the generated expression.
This makes expression evaluation for plugins more flexible and allows
language-specific fixes to reside in their own module, rather than
littering the expression evaluator itself with language-specific fixes.
Modified:
lldb/trunk/include/lldb/Expression/LLVMUserExpression.h
lldb/trunk/include/lldb/Target/LanguageRuntime.h
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
Modified: lldb/trunk/include/lldb/Expression/LLVMUserExpression.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Expression/LLVMUserExpression.h?rev=272800&r1=272799&r2=272800&view=diff
==
--- lldb/trunk/include/lldb/Expression/LLVMUserExpression.h (original)
+++ lldb/trunk/include/lldb/Expression/LLVMUserExpression.h Wed Jun 15 11:19:46
2016
@@ -16,6 +16,9 @@
#include
#include
+// Other libraries and framework includes
+#include "llvm/IR/LegacyPassManager.h"
+
// Project includes
#include "lldb/Expression/UserExpression.h"
@@ -35,6 +38,17 @@ namespace lldb_private
class LLVMUserExpression : public UserExpression
{
public:
+// The IRPasses struct is filled in by a runtime after an expression is
compiled and can be used to to run
+// fixups/analysis passes as required. EarlyPasses are run on the
generated module before lldb runs its own IR
+// fixups and inserts instrumentation code/pointer checks. LatePasses are
run after the module has been processed by
+// llvm, before the module is assembled and run in the ThreadPlan.
+struct IRPasses
+{
+IRPasses() : EarlyPasses(nullptr), LatePasses(nullptr){};
+std::shared_ptr EarlyPasses;
+std::shared_ptr LatePasses;
+};
+
LLVMUserExpression(ExecutionContextScope &exe_scope, const char *expr,
const char *expr_prefix,
lldb::LanguageType language, ResultType desired_type,
const EvaluateExpressionOptions &options);
Modified: lldb/trunk/include/lldb/Target/LanguageRuntime.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/LanguageRuntime.h?rev=272800&r1=272799&r2=272800&view=diff
==
--- lldb/trunk/include/lldb/Target/LanguageRuntime.h (original)
+++ lldb/trunk/include/lldb/Target/LanguageRuntime.h Wed Jun 15 11:19:46 2016
@@ -22,6 +22,8 @@
#include "lldb/Core/ValueObject.h"
#include "lldb/Core/Value.h"
#include "lldb/Target/ExecutionContextScope.h"
+#include "lldb/Expression/LLVMUserExpression.h"
+
#include "clang/Basic/TargetOptions.h"
namespace lldb_private {
@@ -157,6 +159,13 @@ public:
return false;
}
+// Called by ClangExpressionParser::PrepareForExecution to query for any
custom LLVM IR passes
+// that need to be run before an expression is assembled and run.
+virtual bool
+GetIRPasses(LLVMUserExpression::IRPasses &custom_passes)
+{
+return false;
+}
protected:
//--
// Classes that inherit from LanguageRuntime can see and modify these
Modified:
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp?rev=272800&r1=272799&r2=272800&view=diff
==
--- lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
(original)
+++ lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
Wed Jun 15 11:19:46 2016
@@ -837,6 +837,30 @@ ClangExpressionParser::PrepareForExecuti
sc.target_sp = target_sp;
}
+LLVMUserExpression::IRPasses custom_passes;
+{
+auto lang = m_expr.Language();
+if (log)
+log->Printf("%s - Currrent expression language is %s\n",
__FUNCTION__,
+Language::GetNameForLanguageType(lang));
+
+if (lang != lldb::eLanguageTypeUnknown)
+{
+auto runtime = exe_ctx.GetProcessSP()->GetLanguageRuntime(lang);
+if (runtime)
+runtime->GetIRPasses(custom_passes);
+}
+}
+
+if (custom_passes.EarlyPasses)
+{
+if (log)
+log->Printf("%s -
Re: [Lldb-commits] [PATCH] D21221: Fix for PrintStackTraces
ravitheja added a comment. @jasonmolenda The approach suggested seems promising, I look forward to it, if u want I can test it at my end ? once I see it. http://reviews.llvm.org/D21221 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D21221: Fix for PrintStackTraces
jasonmolenda added a comment. Regarding the part of the patch where eh_frame is used unconditionally on Linux systems, I'm hesitant to make a change like that (beyond the notes I mentioned earlier about how I'd do it in FuncUnwinders instead of down in RegisterContextLLDB). Modern gcc's put out eh_frame with prologue and epilogue descriptions on x86_64 - but there's no guarantee that eh_frame we see on a linux or bsd system will come from a modern gcc. For instance, clang (last I checked) does not emit epilogue information in the eh_frame (as did gcc until a few years ago). gdb does pretty well relying exclusively on eh_frame, but the design of the lldb unwinder was to do better than gdb, by using multiple sources of unwind information. Of all the unwind info sources, eh_frame is the most frustrating, IMO. It *can* be everything a debugger could ever need -- but it isn't guaranteed to be that. It's only guaranteed to be enough for exception handling, which is a very different set of requirements from what a debugger needs. And there's no reliable way for a debugger to tell how descriptive an eh_frame entry is. http://reviews.llvm.org/D21221 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
