[Lldb-commits] [PATCH] D52689: [LLDB] - Add support for DW_FORM_implicit_const.
grimar added a comment. In https://reviews.llvm.org/D52689#1253175, @vsk wrote: > Could you describe how the test exercises DW_FORM_implicit_const support? > It's not immediately clear to me. The abbreviation for `foo1` and `foo2` subprograms use it for `DW_AT_decl_file` and `DW_AT_decl_column`: [1] DW_TAG_subprogram DW_CHILDREN_no DW_AT_external DW_FORM_flag_present DW_AT_name DW_FORM_strp DW_AT_decl_file DW_FORM_implicit_const 1 DW_AT_decl_line DW_FORM_data1 DW_AT_decl_column DW_FORM_implicit_const 5 DW_AT_linkage_name DW_FORM_strp DW_AT_type DW_FORM_ref4 DW_AT_low_pcDW_FORM_addr DW_AT_high_pc DW_FORM_data8 DW_AT_frame_baseDW_FORM_exprloc DW_AT_call_all_callsDW_FORM_flag_present https://reviews.llvm.org/D52689 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r343683 - Pull FixupBreakpointPCAsNeeded into base class
Author: labath
Date: Wed Oct 3 05:29:33 2018
New Revision: 343683
URL: http://llvm.org/viewvc/llvm-project?rev=343683&view=rev
Log:
Pull FixupBreakpointPCAsNeeded into base class
Summary:
This function existed (with identical code) in both NativeProcessLinux
and NativeProcessNetBSD, and it is likely that it would be useful to any
future implementation of NativeProcessProtocol.
Therefore I move it to the base class.
Reviewers: krytarowski
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D52719
Modified:
lldb/trunk/include/lldb/Host/common/NativeProcessProtocol.h
lldb/trunk/source/Host/common/NativeProcessProtocol.cpp
lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp
lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.h
lldb/trunk/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp
lldb/trunk/source/Plugins/Process/NetBSD/NativeProcessNetBSD.h
Modified: lldb/trunk/include/lldb/Host/common/NativeProcessProtocol.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Host/common/NativeProcessProtocol.h?rev=343683&r1=343682&r2=343683&view=diff
==
--- lldb/trunk/include/lldb/Host/common/NativeProcessProtocol.h (original)
+++ lldb/trunk/include/lldb/Host/common/NativeProcessProtocol.h Wed Oct 3
05:29:33 2018
@@ -457,6 +457,11 @@ protected:
/// PC, this offset will be the size of the breakpoint opcode.
virtual size_t GetSoftwareBreakpointPCOffset();
+ // Adjust the thread's PC after hitting a software breakpoint. On
+ // architectures where the PC points after the breakpoint instruction, this
+ // resets it to point to the breakpoint itself.
+ void FixupBreakpointPCAsNeeded(NativeThreadProtocol &thread);
+
// ---
/// Notify the delegate that an exec occurred.
///
Modified: lldb/trunk/source/Host/common/NativeProcessProtocol.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Host/common/NativeProcessProtocol.cpp?rev=343683&r1=343682&r2=343683&view=diff
==
--- lldb/trunk/source/Host/common/NativeProcessProtocol.cpp (original)
+++ lldb/trunk/source/Host/common/NativeProcessProtocol.cpp Wed Oct 3 05:29:33
2018
@@ -432,6 +432,68 @@ size_t NativeProcessProtocol::GetSoftwar
}
}
+void NativeProcessProtocol::FixupBreakpointPCAsNeeded(
+NativeThreadProtocol &thread) {
+ Log *log = GetLogIfAnyCategoriesSet(LIBLLDB_LOG_BREAKPOINTS);
+
+ Status error;
+
+ // Find out the size of a breakpoint (might depend on where we are in the
+ // code).
+ NativeRegisterContext &context = thread.GetRegisterContext();
+
+ uint32_t breakpoint_size = GetSoftwareBreakpointPCOffset();
+ LLDB_LOG(log, "breakpoint size: {0}", breakpoint_size);
+ if (breakpoint_size == 0)
+return;
+
+ // First try probing for a breakpoint at a software breakpoint location: PC -
+ // breakpoint size.
+ const lldb::addr_t initial_pc_addr = context.GetPCfromBreakpointLocation();
+ lldb::addr_t breakpoint_addr = initial_pc_addr;
+ // Do not allow breakpoint probe to wrap around.
+ if (breakpoint_addr >= breakpoint_size)
+breakpoint_addr -= breakpoint_size;
+
+ // Check if we stopped because of a breakpoint.
+ NativeBreakpointSP breakpoint_sp;
+ error = m_breakpoint_list.GetBreakpoint(breakpoint_addr, breakpoint_sp);
+ if (!error.Success() || !breakpoint_sp) {
+// We didn't find one at a software probe location. Nothing to do.
+LLDB_LOG(log,
+ "pid {0} no lldb breakpoint found at current pc with "
+ "adjustment: {1}",
+ GetID(), breakpoint_addr);
+return;
+ }
+
+ // If the breakpoint is not a software breakpoint, nothing to do.
+ if (!breakpoint_sp->IsSoftwareBreakpoint()) {
+LLDB_LOG(
+log,
+"pid {0} breakpoint found at {1:x}, not software, nothing to adjust",
+GetID(), breakpoint_addr);
+return;
+ }
+
+ //
+ // We have a software breakpoint and need to adjust the PC.
+ //
+
+ // Change the program counter.
+ LLDB_LOG(log, "pid {0} tid {1}: changing PC from {2:x} to {3:x}", GetID(),
+ thread.GetID(), initial_pc_addr, breakpoint_addr);
+
+ error = context.SetPC(breakpoint_addr);
+ if (error.Fail()) {
+// This can happen in case the process was killed between the time we read
+// the PC and when we are updating it. There's nothing better to do than to
+// swallow the error.
+LLDB_LOG(log, "pid {0} tid {1}: failed to set PC: {2}", GetID(),
+ thread.GetID(), error);
+ }
+}
+
Status NativeProcessProtocol::RemoveBreakpoint(lldb::addr_t addr,
bool hardware) {
if (hardware)
Modified: lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Linux/Nat
[Lldb-commits] [PATCH] D52719: Pull FixupBreakpointPCAsNeeded into base class
This revision was automatically updated to reflect the committed changes.
Closed by commit rL343683: Pull FixupBreakpointPCAsNeeded into base class
(authored by labath, committed by ).
Herald added a subscriber: llvm-commits.
Repository:
rL LLVM
https://reviews.llvm.org/D52719
Files:
lldb/trunk/include/lldb/Host/common/NativeProcessProtocol.h
lldb/trunk/source/Host/common/NativeProcessProtocol.cpp
lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp
lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.h
lldb/trunk/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp
lldb/trunk/source/Plugins/Process/NetBSD/NativeProcessNetBSD.h
Index: lldb/trunk/include/lldb/Host/common/NativeProcessProtocol.h
===
--- lldb/trunk/include/lldb/Host/common/NativeProcessProtocol.h
+++ lldb/trunk/include/lldb/Host/common/NativeProcessProtocol.h
@@ -457,6 +457,11 @@
/// PC, this offset will be the size of the breakpoint opcode.
virtual size_t GetSoftwareBreakpointPCOffset();
+ // Adjust the thread's PC after hitting a software breakpoint. On
+ // architectures where the PC points after the breakpoint instruction, this
+ // resets it to point to the breakpoint itself.
+ void FixupBreakpointPCAsNeeded(NativeThreadProtocol &thread);
+
// ---
/// Notify the delegate that an exec occurred.
///
Index: lldb/trunk/source/Plugins/Process/NetBSD/NativeProcessNetBSD.h
===
--- lldb/trunk/source/Plugins/Process/NetBSD/NativeProcessNetBSD.h
+++ lldb/trunk/source/Plugins/Process/NetBSD/NativeProcessNetBSD.h
@@ -112,7 +112,6 @@
void MonitorSIGTRAP(lldb::pid_t pid);
void MonitorSignal(lldb::pid_t pid, int signal);
- Status FixupBreakpointPCAsNeeded(NativeThreadNetBSD &thread);
Status PopulateMemoryRegionCache();
void SigchldHandler();
Index: lldb/trunk/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp
===
--- lldb/trunk/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp
+++ lldb/trunk/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp
@@ -322,81 +322,6 @@
return error;
}
-Status
-NativeProcessNetBSD::FixupBreakpointPCAsNeeded(NativeThreadNetBSD &thread) {
- Log *log(ProcessPOSIXLog::GetLogIfAllCategoriesSet(POSIX_LOG_BREAKPOINTS));
- Status error;
- // Find out the size of a breakpoint (might depend on where we are in the
- // code).
- NativeRegisterContext& context = thread.GetRegisterContext();
- uint32_t breakpoint_size = GetSoftwareBreakpointPCOffset();
- LLDB_LOG(log, "breakpoint size: {0}", breakpoint_size);
-
- // First try probing for a breakpoint at a software breakpoint location: PC -
- // breakpoint size.
- const lldb::addr_t initial_pc_addr =
- context.GetPCfromBreakpointLocation();
- lldb::addr_t breakpoint_addr = initial_pc_addr;
- if (breakpoint_size > 0) {
-// Do not allow breakpoint probe to wrap around.
-if (breakpoint_addr >= breakpoint_size)
- breakpoint_addr -= breakpoint_size;
- }
- // Check if we stopped because of a breakpoint.
- NativeBreakpointSP breakpoint_sp;
- error = m_breakpoint_list.GetBreakpoint(breakpoint_addr, breakpoint_sp);
- if (!error.Success() || !breakpoint_sp) {
-// We didn't find one at a software probe location. Nothing to do.
-LLDB_LOG(log,
- "pid {0} no lldb breakpoint found at current pc with "
- "adjustment: {1}",
- GetID(), breakpoint_addr);
-return Status();
- }
- // If the breakpoint is not a software breakpoint, nothing to do.
- if (!breakpoint_sp->IsSoftwareBreakpoint()) {
-LLDB_LOG(
-log,
-"pid {0} breakpoint found at {1:x}, not software, nothing to adjust",
-GetID(), breakpoint_addr);
-return Status();
- }
- //
- // We have a software breakpoint and need to adjust the PC.
- //
- // Sanity check.
- if (breakpoint_size == 0) {
-// Nothing to do! How did we get here?
-LLDB_LOG(log,
- "pid {0} breakpoint found at {1:x}, it is software, but the "
- "size is zero, nothing to do (unexpected)",
- GetID(), breakpoint_addr);
-return Status();
- }
- //
- // We have a software breakpoint and need to adjust the PC.
- //
- // Sanity check.
- if (breakpoint_size == 0) {
-// Nothing to do! How did we get here?
-LLDB_LOG(log,
- "pid {0} breakpoint found at {1:x}, it is software, but the "
- "size is zero, nothing to do (unexpected)",
- GetID(), breakpoint_addr);
-return Status();
- }
- // Change the program counter.
- LLDB_LOG(log, "pid {0} tid {1}: changing PC from {2:x} to {3:x}", GetID(),
- thread.GetID(), initial_pc_addr, breakpoint_addr);
- error = context.SetPC(breakpoint_addr);
- if (error.Fail()) {
-LLDB_LOG(log, "pid {0} tid
[Lldb-commits] [PATCH] D52772: [Settings] Make "settings set" without a value equivalent to "settings clear"
JDevlieghere added a comment. In https://reviews.llvm.org/D52772#1252656, @jingham wrote: > Would it be possible for the exporter to notice empty settings and write > "settings clear" instead? I don't think we can if we want to re-use the existing dump infrastructure, unless there's a way to ask a `Property` if is empty/has a default value? > I'm worried that if you have a complicated setting, and the you do: > > (lldb) settings set target.some-complex-setting > > and decide you are wrong, you don't want to change the complex setting, then > you have to know to delete the text - hitting a return is actually > destructive. This sounds like a very specific issue, though. You have the same problem if the value is something like a string and the user accidentally types one more character. What kind of scenario do you have in mind where a user would be able to type the command but not know how to delete it? I'm definitely not saying it's not a valid reason to consider alternatives and the current behavior is nice, but do you consider this a showstopper? Repository: rLLDB LLDB https://reviews.llvm.org/D52772 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D52788: Add EchoCommentCommands to CommandInterpreterRunOptions in addition to the existing EchoCommands and expose both as interpreter settings.
JDevlieghere added a comment. Thanks for working on this Stefan, I'm really excited about this feature! Regarding the code, I don't have comments that weren't already brought up by the other reviewers. https://reviews.llvm.org/D52788 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r343695 - Skip test with older versions of clang
Author: adrian Date: Wed Oct 3 09:24:14 2018 New Revision: 343695 URL: http://llvm.org/viewvc/llvm-project?rev=343695&view=rev Log: Skip test with older versions of clang Modified: lldb/trunk/packages/Python/lldbsuite/test/functionalities/target_var/TestTargetVar.py Modified: lldb/trunk/packages/Python/lldbsuite/test/functionalities/target_var/TestTargetVar.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/target_var/TestTargetVar.py?rev=343695&r1=343694&r2=343695&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/functionalities/target_var/TestTargetVar.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/target_var/TestTargetVar.py Wed Oct 3 09:24:14 2018 @@ -16,6 +16,7 @@ class targetCommandTestCase(TestBase): @skipUnlessDarwin @skipIfDarwinEmbedded # needs x86_64 @skipIf(debug_info="gmodules") # not relevant +@skipIf(compiler="clang", compiler_version=['<', '7.0']) def testTargetVarExpr(self): self.build() lldbutil.run_to_name_breakpoint(self, 'main') ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D52772: [Settings] Make "settings set" without a value equivalent to "settings clear"
jingham added a comment. I'm thinking of the scenario where you type: (lldb) settings set target.run-args and then decide you didn't want to change the run-args after all. Before this change hitting return used to be a way to dismiss the settings operation, and that actually seems a pretty natural thing to do - especially given that there is a "clear" operation. Repository: rLLDB LLDB https://reviews.llvm.org/D52772 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D52772: [Settings] Make "settings set" without a value equivalent to "settings clear"
jingham added a comment. And more, I just like operations to be explicit and not have overloads like "settings set property" == "settings clear property". Repository: rLLDB LLDB https://reviews.llvm.org/D52772 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D50478: Add support for artificial tail call frames
aprantl added a comment. This looks pretty good! I have one last question about CallEdge inside. Comment at: lldb/include/lldb/Symbol/Function.h:304 +public: + CallEdge(const char *mangled_name, lldb::addr_t return_pc); + Does this also work for C functions? If yes, would `symbol_name` be a more accurate description? Is this pointer globally unique in the program, or can two mangled names appear in a legal C program that don't refer to the same function? Comment at: lldb/include/lldb/Target/StackFrame.h:65 + +/// An artificial stack frame (e.g a synthesized result of inferring +/// missing tail call frames from a backtrace) with limited support for `e.g.,` Comment at: lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/ambiguous_tail_call_seq2/TestAmbiguousTailCallSeq2.py:5 +lldbinline.MakeInlineTest(__file__, globals(), +[decorators.skipUnlessHasCallSiteInfo]) This test should be restricted to only run with clang as the compiler or the -glldb flag won't work. I see. It is implicit in in skipUnlessHasCallSiteInfo — perhaps we should just generally add -glldb to CFLAGS? It's not a bug deal. https://reviews.llvm.org/D50478 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D52788: Add EchoCommentCommands to CommandInterpreterRunOptions in addition to the existing EchoCommands and expose both as interpreter settings.
aprantl added inline comments. Comment at: source/Interpreter/CommandInterpreter.cpp:2733 + + const char *k_space_characters = "\t\n\v\f\r "; + size_t first_non_space = line.find_first_not_of(k_space_characters); sgraenitz wrote: > sgraenitz wrote: > > shafik wrote: > > > This looks like duplicate code from from `HandleCommand` I also see that > > > at the the top of the file there is `k_white_space` although I am not > > > sure why it is not in a anonymous namespace and why perhaps it is not a > > > `ConstString` > > Right, this is confusing. Any chance the extra escape sequences could make > > a difference in the context of line-wise command strings? > > Anyway, yes I would feel better with one set of white space characters. > > Will check the details. > > ``` > > \fForm Feed > > \rCarriage Return > > \vVertical Tab > > ``` > We have more of them in CommandObjectCommands.cpp:1131, > FormattersContainer.h:62, Args.cpp:397 and MIUtilString.cpp:511. LLVM has no > named definition we could use. Drive-by-comment: It's also always good to double-check whether functionality like this already exists in either LLVM's StringRef or StringExtras.h (https://llvm.org/doxygen/StringExtras_8h_source.html). https://reviews.llvm.org/D52788 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D50478: Add support for artificial tail call frames
vsk updated this revision to Diff 168155.
vsk marked an inline comment as done.
vsk added a comment.
- Address feedback from Adrian.
https://reviews.llvm.org/D50478
Files:
lldb/include/lldb/API/SBFrame.h
lldb/include/lldb/Core/FormatEntity.h
lldb/include/lldb/Symbol/Block.h
lldb/include/lldb/Symbol/Function.h
lldb/include/lldb/Symbol/SymbolFile.h
lldb/include/lldb/Target/StackFrame.h
lldb/include/lldb/Target/StackFrameList.h
lldb/include/lldb/Target/ThreadPlanStepOut.h
lldb/packages/Python/lldbsuite/test/decorators.py
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/ambiguous_tail_call_seq1/Makefile
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/ambiguous_tail_call_seq1/TestAmbiguousTailCallSeq1.py
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/ambiguous_tail_call_seq1/main.cpp
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/ambiguous_tail_call_seq2/Makefile
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/ambiguous_tail_call_seq2/TestAmbiguousTailCallSeq2.py
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/ambiguous_tail_call_seq2/main.cpp
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/disambiguate_call_site/Makefile
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/disambiguate_call_site/TestDisambiguateCallSite.py
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/disambiguate_call_site/main.cpp
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/disambiguate_paths_to_common_sink/Makefile
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/disambiguate_paths_to_common_sink/TestDisambiguatePathsToCommonSink.py
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/disambiguate_paths_to_common_sink/main.cpp
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/disambiguate_tail_call_seq/Makefile
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/disambiguate_tail_call_seq/TestDisambiguateTailCallSeq.py
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/disambiguate_tail_call_seq/main.cpp
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/inlining_and_tail_calls/Makefile
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/inlining_and_tail_calls/TestInliningAndTailCalls.py
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/inlining_and_tail_calls/main.cpp
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/sbapi_support/Makefile
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/sbapi_support/TestTailCallFrameSBAPI.py
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/sbapi_support/main.cpp
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/thread_step_out_message/Makefile
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/thread_step_out_message/TestArtificialFrameStepOutMessage.py
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/thread_step_out_message/main.cpp
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/thread_step_out_or_return/Makefile
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/thread_step_out_or_return/TestSteppingOutWithArtificialFrames.py
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/thread_step_out_or_return/main.cpp
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/unambiguous_sequence/Makefile
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/unambiguous_sequence/TestUnambiguousTailCalls.py
lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/unambiguous_sequence/main.cpp
lldb/scripts/interface/SBFrame.i
lldb/source/API/SBFrame.cpp
lldb/source/Core/Debugger.cpp
lldb/source/Core/FormatEntity.cpp
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h
lldb/source/Symbol/Block.cpp
lldb/source/Symbol/Function.cpp
lldb/source/Target/StackFrame.cpp
lldb/source/Target/StackFrameList.cpp
lldb/source/Target/ThreadPlanStepOut.cpp
Index: lldb/source/Target/ThreadPlanStepOut.cpp
===
--- lldb/source/Target/ThreadPlanStepOut.cpp
+++ lldb/source/Target/ThreadPlanStepOut.cpp
@@ -48,26 +48,44 @@
m_return_addr(LLDB_INVALID_ADDRESS), m_stop_others(stop_others),
m_immediate_step_from_function(nullptr),
m_calculate_return_value(gather_return_value) {
+ Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_STEP));
SetFlagsToDefault();
SetupAv
[Lldb-commits] [PATCH] D50478: Add support for artificial tail call frames
vsk added inline comments. Comment at: lldb/include/lldb/Symbol/Function.h:304 +public: + CallEdge(const char *mangled_name, lldb::addr_t return_pc); + aprantl wrote: > Does this also work for C functions? If yes, would `symbol_name` be a more > accurate description? > > Is this pointer globally unique in the program, or can two mangled names > appear in a legal C program that don't refer to the same function? Yes, C functions are handled. I'll use "symbol_name", hopefully that makes it clearer. Comment at: lldb/include/lldb/Symbol/Function.h:304 +public: + CallEdge(const char *mangled_name, lldb::addr_t return_pc); + vsk wrote: > aprantl wrote: > > Does this also work for C functions? If yes, would `symbol_name` be a more > > accurate description? > > > > Is this pointer globally unique in the program, or can two mangled names > > appear in a legal C program that don't refer to the same function? > Yes, C functions are handled. I'll use "symbol_name", hopefully that makes it > clearer. Great question. No, a symbol name is not necessarily globally unique. Prior to C11, the one-definition-rule doesn't apply. Even with the ODR, a private symbol in a shared library may have the same name as a strong definition in the main executable. I haven't tried to disambiguate ODR conflicts in this patch. What happens when a conflict occurs is: `FindFunctionSymbols` prioritizes the symbol in the main executable, and if the call edge's return PC doesn't exactly match what's in the register state we decline to create any artificial frames. I.e. in the presence of ODR conflicts, we only present artificial frames when we're 100% sure they are accurate. Handling ODR conflicts is a 'to do', though. I'll make an explicit note of that here. Comment at: lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/ambiguous_tail_call_seq2/TestAmbiguousTailCallSeq2.py:5 +lldbinline.MakeInlineTest(__file__, globals(), +[decorators.skipUnlessHasCallSiteInfo]) aprantl wrote: > This test should be restricted to only run with clang as the compiler or the > -glldb flag won't work. > > I see. It is implicit in in skipUnlessHasCallSiteInfo — perhaps we should > just generally add -glldb to CFLAGS? It's not a bug deal. Yes, skipUnlessHasCallSiteInfo requires clang for now. I don't think we can add -glldb to a higher-level CFLAGS variable without breaking compiling with gcc? https://reviews.llvm.org/D50478 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D50478: Add support for artificial tail call frames
aprantl added inline comments. Comment at: lldb/include/lldb/Symbol/Function.h:304 +public: + CallEdge(const char *mangled_name, lldb::addr_t return_pc); + vsk wrote: > vsk wrote: > > aprantl wrote: > > > Does this also work for C functions? If yes, would `symbol_name` be a > > > more accurate description? > > > > > > Is this pointer globally unique in the program, or can two mangled names > > > appear in a legal C program that don't refer to the same function? > > Yes, C functions are handled. I'll use "symbol_name", hopefully that makes > > it clearer. > Great question. No, a symbol name is not necessarily globally unique. Prior > to C11, the one-definition-rule doesn't apply. Even with the ODR, a private > symbol in a shared library may have the same name as a strong definition in > the main executable. > > I haven't tried to disambiguate ODR conflicts in this patch. What happens > when a conflict occurs is: `FindFunctionSymbols` prioritizes the symbol in > the main executable, and if the call edge's return PC doesn't exactly match > what's in the register state we decline to create any artificial frames. I.e. > in the presence of ODR conflicts, we only present artificial frames when > we're 100% sure they are accurate. > > Handling ODR conflicts is a 'to do', though. I'll make an explicit note of > that here. Thanks! It might be interesting to grep through an XNU dsym to see just how common conflicts are in typical C code. https://reviews.llvm.org/D50478 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r343718 - Adding skipIf to std::variant libc++ data-formatter test since get is not available before macOS 10.14
Author: shafik Date: Wed Oct 3 13:52:56 2018 New Revision: 343718 URL: http://llvm.org/viewvc/llvm-project?rev=343718&view=rev Log: Adding skipIf to std::variant libc++ data-formatter test since get is not available before macOS 10.14 Patch by Shafik Yaghmour Modified: lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/variant/TestDataFormatterLibcxxVariant.py Modified: lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/variant/TestDataFormatterLibcxxVariant.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/variant/TestDataFormatterLibcxxVariant.py?rev=343718&r1=343717&r2=343718&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/variant/TestDataFormatterLibcxxVariant.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/variant/TestDataFormatterLibcxxVariant.py Wed Oct 3 13:52:56 2018 @@ -21,6 +21,8 @@ class LibcxxOptionalDataFormatterTestCas @skipIf(oslist=no_match(["macosx"]), compiler="clang", compiler_version=['<', '5.0']) ## We are skipping gcc version less that 5.1 since this test requires -std=c++17 @skipIf(compiler="gcc", compiler_version=['<', '5.1']) +## std::get is unavailable for std::variant before macOS 10.14 +@skipIf(macos_version=["<", "10.14"]) def test_with_run_command(self): """Test that that file and class static variables display correctly.""" ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D51874: Fix buildbot regression by rL339929: NameError: global name 'test_directory' is not defined
davide accepted this revision. davide added a comment. This revision is now accepted and ready to land. I think this looks fine. Vedant, thoughts? Repository: rLLDB LLDB https://reviews.llvm.org/D51874 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D50478: Add support for artificial tail call frames
vsk added inline comments. Comment at: lldb/include/lldb/Symbol/Function.h:304 +public: + CallEdge(const char *mangled_name, lldb::addr_t return_pc); + aprantl wrote: > vsk wrote: > > vsk wrote: > > > aprantl wrote: > > > > Does this also work for C functions? If yes, would `symbol_name` be a > > > > more accurate description? > > > > > > > > Is this pointer globally unique in the program, or can two mangled > > > > names appear in a legal C program that don't refer to the same function? > > > Yes, C functions are handled. I'll use "symbol_name", hopefully that > > > makes it clearer. > > Great question. No, a symbol name is not necessarily globally unique. Prior > > to C11, the one-definition-rule doesn't apply. Even with the ODR, a private > > symbol in a shared library may have the same name as a strong definition in > > the main executable. > > > > I haven't tried to disambiguate ODR conflicts in this patch. What happens > > when a conflict occurs is: `FindFunctionSymbols` prioritizes the symbol in > > the main executable, and if the call edge's return PC doesn't exactly match > > what's in the register state we decline to create any artificial frames. > > I.e. in the presence of ODR conflicts, we only present artificial frames > > when we're 100% sure they are accurate. > > > > Handling ODR conflicts is a 'to do', though. I'll make an explicit note of > > that here. > Thanks! It might be interesting to grep through an XNU dsym to see just how > common conflicts are in typical C code. Of a total of ~27,000 function names in xnu, 140 names were duplicates. In every case I spot-checked, a subprogram with a duplicate AT_name had a unique AT_linkage_name. So, well under 0.5% in that project. https://reviews.llvm.org/D50478 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D50478: Add support for artificial tail call frames
aprantl accepted this revision. aprantl added a comment. This revision is now accepted and ready to land. Thanks! https://reviews.llvm.org/D50478 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D51874: Fix buildbot regression by rL339929: NameError: global name 'test_directory' is not defined
vsk added inline comments. Comment at: packages/Python/lldbsuite/test/dosep.py:1693 for core in cores: dst = core.replace(test_directory, "")[1:] dst = dst.replace(os.path.sep, "-") Instead of redefining test_directory, please use 'test_subdir' in the call to core.replace. That leaves the logic to find the right path in configuration.get_absolute_path_to_root_test_dir. Repository: rLLDB LLDB https://reviews.llvm.org/D51874 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r343726 - Fix buildbot regression by rL339929: NameError: global name 'test_directory' is not defined
Author: jankratochvil
Date: Wed Oct 3 14:42:54 2018
New Revision: 343726
URL: http://llvm.org/viewvc/llvm-project?rev=343726&view=rev
Log:
Fix buildbot regression by rL339929: NameError: global name 'test_directory' is
not defined
With buildbot slave under test - I get after rL339929:
http://lab.llvm.org:8014/builders/lldb-x86_64-fedora-28-cmake/builds/243/steps/test1/logs/stdio
File
"/home/buildbot/lldbroot/lldb-x86_64-fedora-28-cmake/scripts/../llvm/tools/lldb/test/dotest.py",
line 7, in
lldbsuite.test.run_suite()
File
"/quad/home/buildbot/lldbroot/lldb-x86_64-fedora-28-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/dotest.py",
line 1177, in run_suite
configuration.results_formatter_object)
File
"/quad/home/buildbot/lldbroot/lldb-x86_64-fedora-28-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/dosep.py",
line 1692, in main
dst = core.replace(test_directory, "")[1:]
NameError: global name 'test_directory' is not defined
Patch by Vedant Kumar.
Differential Revision: https://reviews.llvm.org/D51874
Modified:
lldb/trunk/packages/Python/lldbsuite/test/dosep.py
Modified: lldb/trunk/packages/Python/lldbsuite/test/dosep.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dosep.py?rev=343726&r1=343725&r2=343726&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/dosep.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/dosep.py Wed Oct 3 14:42:54 2018
@@ -1689,7 +1689,7 @@ def main(num_threads, test_runner_name,
# move core files into session dir
cores = find('core.*', test_subdir)
for core in cores:
-dst = core.replace(test_directory, "")[1:]
+dst = core.replace(test_subdir, "")[1:]
dst = dst.replace(os.path.sep, "-")
os.rename(core, os.path.join(session_dir, dst))
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D51874: Fix buildbot regression by rL339929: NameError: global name 'test_directory' is not defined
This revision was automatically updated to reflect the committed changes.
Closed by commit rLLDB343726: Fix buildbot regression by rL339929: NameError:
global name 'test_directory' is… (authored by jankratochvil,
committed by ).
Changed prior to commit:
https://reviews.llvm.org/D51874?vs=164709&id=168179#toc
Repository:
rLLDB LLDB
https://reviews.llvm.org/D51874
Files:
packages/Python/lldbsuite/test/dosep.py
Index: packages/Python/lldbsuite/test/dosep.py
===
--- packages/Python/lldbsuite/test/dosep.py
+++ packages/Python/lldbsuite/test/dosep.py
@@ -1689,7 +1689,7 @@
# move core files into session dir
cores = find('core.*', test_subdir)
for core in cores:
-dst = core.replace(test_directory, "")[1:]
+dst = core.replace(test_subdir, "")[1:]
dst = dst.replace(os.path.sep, "-")
os.rename(core, os.path.join(session_dir, dst))
Index: packages/Python/lldbsuite/test/dosep.py
===
--- packages/Python/lldbsuite/test/dosep.py
+++ packages/Python/lldbsuite/test/dosep.py
@@ -1689,7 +1689,7 @@
# move core files into session dir
cores = find('core.*', test_subdir)
for core in cores:
-dst = core.replace(test_directory, "")[1:]
+dst = core.replace(test_subdir, "")[1:]
dst = dst.replace(os.path.sep, "-")
os.rename(core, os.path.join(session_dir, dst))
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D52678: DWARFExpression: Resolve file addresses in the linked module
vsk added inline comments. Comment at: packages/Python/lldbsuite/test/functionalities/target_var/globals.ll:1 +source_filename = "globals.c" +target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128" Should we check in bitcode instead? That might make it easier to avoid breakage when the textual IR format changes. Repository: rLLDB LLDB https://reviews.llvm.org/D52678 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D52851: Adding support to step into the callable wrapped by libc++ std::function
shafik created this revision.
shafik added reviewers: jingham, davide, aprantl.
Herald added a reviewer: EricWF.
- Adding support to step into the callable wrapped by libc++ std::function
- Adding test to validate that functionality
https://reviews.llvm.org/D52851
Files:
include/lldb/Target/CPPLanguageRuntime.h
packages/Python/lldbsuite/test/lang/cpp/std-function-step-into-callable/Makefile
packages/Python/lldbsuite/test/lang/cpp/std-function-step-into-callable/TestStdFunctionStepIntoCallable.py
packages/Python/lldbsuite/test/lang/cpp/std-function-step-into-callable/main.cpp
source/Target/CPPLanguageRuntime.cpp
source/Target/ThreadPlanStepThrough.cpp
Index: source/Target/ThreadPlanStepThrough.cpp
===
--- source/Target/ThreadPlanStepThrough.cpp
+++ source/Target/ThreadPlanStepThrough.cpp
@@ -13,6 +13,7 @@
// Project includes
#include "lldb/Target/ThreadPlanStepThrough.h"
#include "lldb/Breakpoint/Breakpoint.h"
+#include "lldb/Target/CPPLanguageRuntime.h"
#include "lldb/Target/DynamicLoader.h"
#include "lldb/Target/ObjCLanguageRuntime.h"
#include "lldb/Target/Process.h"
@@ -95,6 +96,13 @@
if (objc_runtime)
m_sub_plan_sp =
objc_runtime->GetStepThroughTrampolinePlan(m_thread, m_stop_others);
+
+CPPLanguageRuntime *cpp_runtime =
+m_thread.GetProcess()->GetCPPLanguageRuntime();
+
+if (cpp_runtime)
+ m_sub_plan_sp =
+ cpp_runtime->GetStepThroughTrampolinePlan(m_thread, m_stop_others);
}
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_STEP));
Index: source/Target/CPPLanguageRuntime.cpp
===
--- source/Target/CPPLanguageRuntime.cpp
+++ source/Target/CPPLanguageRuntime.cpp
@@ -26,6 +26,7 @@
#include "lldb/Target/SectionLoadList.h"
#include "lldb/Target/StackFrame.h"
#include "lldb/Target/ThreadPlanRunToAddress.h"
+#include "lldb/Target/ThreadPlanStepInRange.h"
using namespace lldb;
using namespace lldb_private;
@@ -158,7 +159,6 @@
// We do this by find the first < and , and extracting in between.
//
// This covers the case of the lambda known at compile time.
- //
size_t first_open_angle_bracket = vtable_name.find('<') + 1;
size_t first_comma = vtable_name.find_first_of(',');
@@ -262,3 +262,77 @@
return optional_info;
}
+
+lldb::ThreadPlanSP
+CPPLanguageRuntime::GetStepThroughTrampolinePlan(Thread &thread,
+ bool stop_others) {
+ ThreadPlanSP ret_plan_sp;
+
+ lldb::addr_t curr_pc = thread.GetRegisterContext()->GetPC();
+
+ TargetSP target_sp(thread.CalculateTarget());
+
+ if (target_sp->GetSectionLoadList().IsEmpty())
+return ret_plan_sp;
+
+ Address pc_addr_resolved;
+ SymbolContext sc;
+ Symbol *symbol;
+
+ if (!target_sp->GetSectionLoadList().ResolveLoadAddress(curr_pc,
+ pc_addr_resolved))
+return ret_plan_sp;
+
+ target_sp->GetImages().ResolveSymbolContextForAddress(
+ pc_addr_resolved, eSymbolContextEverything, sc);
+ symbol = sc.symbol;
+
+ if (symbol == nullptr)
+return ret_plan_sp;
+
+ llvm::StringRef function_name(symbol->GetName().GetCString());
+
+ // Handling the case where we are attempting to step into std::function.
+ // Currently due to the the:
+ //
+ //target.process.thread.step-avoid-regexp
+ //
+ // setting we will currenly step right out of standard library code.
+ //
+ // The new behavior will be that we will attempt to obtain the wrapped
+ // callable via FindLibCppStdFunctionCallableInfo() and if we find it we
+ // will return a ThreadPlanRunToAddress to the callable. Therefore we will
+ // step into the wrapped callable.
+ //
+ bool found_expected_start_string =
+ function_name.startswith("std::__1::function<");
+
+ if (!found_expected_start_string)
+return ret_plan_sp;
+
+ AddressRange range_of_curr_func;
+ sc.GetAddressRange(eSymbolContextEverything, 0, false, range_of_curr_func);
+
+ StackFrameSP frame = thread.GetStackFrameAtIndex(0);
+
+ if (frame) {
+ValueObjectSP value_sp = frame->FindVariable(ConstString("this"));
+
+CPPLanguageRuntime::LibCppStdFunctionCallableInfo callable_info =
+FindLibCppStdFunctionCallableInfo(value_sp);
+
+if (callable_info.callable_case != LibCppStdFunctionCallableCase::Invalid &&
+value_sp->GetValueIsValid()) {
+ ret_plan_sp.reset(new ThreadPlanRunToAddress(
+ thread, callable_info.callable_address, stop_others));
+ return ret_plan_sp;
+} else {
+ ret_plan_sp.reset(new ThreadPlanStepInRange(thread, range_of_curr_func,
+ sc, eOnlyThisThread,
+ eLazyBoolYes, eLazyBoolYes));
+ return ret_plan_sp;
+}
+ }
+
+ return ret_plan_sp;
+}
Index: packages/Python/lldbsuite/test/lang/cpp/std-func
[Lldb-commits] [PATCH] D52851: Adding support to step into the callable wrapped by libc++ std::function
davide added a comment. Some basic comments. Haven't looked at the implementation very closely, I'll do that probably tomorrow. Thanks for working on this! Comment at: include/lldb/Target/CPPLanguageRuntime.h:59-60 + lldb::ThreadPlanSP GetStepThroughTrampolinePlan(Thread &thread, + bool stop_others); + Please add a doxygen comment to this function. (I understand the surrounding ones are not commented, but we should start somewhere)/ Comment at: packages/Python/lldbsuite/test/lang/cpp/std-function-step-into-callable/TestStdFunctionStepIntoCallable.py:1-3 +""" +Test lldb data formatter subsystem. +""" This comment seems a little outdated. Comment at: packages/Python/lldbsuite/test/lang/cpp/std-function-step-into-callable/TestStdFunctionStepIntoCallable.py:8-9 + +import os +import time +import lldb I'm not sure you need these. Comment at: packages/Python/lldbsuite/test/lang/cpp/std-function-step-into-callable/TestStdFunctionStepIntoCallable.py:27-28 + +@add_test_categories(["libc++"]) +def test(self): +"""Test that std::function as defined by libc++ is correctly printed by LLDB""" Is this affected by the debug info variant used? (i.e. dSYM/gmodules/DWARF/dwo). If not, this could be a `NO_DEBUG_INFO` test Comment at: packages/Python/lldbsuite/test/lang/cpp/std-function-step-into-callable/TestStdFunctionStepIntoCallable.py:56-73 +self.assertEqual( self.thread.GetFrameAtIndex(0).GetLineEntry().GetLine(), 13 ) ; +self.process.Continue() + +self.thread.StepInto() +self.assertEqual( self.thread.GetFrameAtIndex(0).GetLineEntry().GetLine(), 28 ) ; +self.process.Continue() + All these lines check hardcoded make me a little nervous, as they're really fragile. Can you make them parametric at least? so that if somebody slides down the test case they're still valid (i.e. base + offset) Comment at: packages/Python/lldbsuite/test/lang/cpp/std-function-step-into-callable/main.cpp:1-9 +//===-- main.cpp --*- C++ -*-===// +// +// The LLVM Compiler Infrastructure +// +// This file is distributed under the University of Illinois Open Source +// License. See LICENSE.TXT for details. +// You don't need a license for the test case, I think. Comment at: source/Target/ThreadPlanStepThrough.cpp:99-105 + +CPPLanguageRuntime *cpp_runtime = +m_thread.GetProcess()->GetCPPLanguageRuntime(); + +if (cpp_runtime) + m_sub_plan_sp = + cpp_runtime->GetStepThroughTrampolinePlan(m_thread, m_stop_others); Can you add a comment here? https://reviews.llvm.org/D52851 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D52678: DWARFExpression: Resolve file addresses in the linked module
davide added inline comments. Comment at: packages/Python/lldbsuite/test/functionalities/target_var/globals.ll:1 +source_filename = "globals.c" +target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128" vsk wrote: > Should we check in bitcode instead? That might make it easier to avoid > breakage when the textual IR format changes. But also will be more painful to regenerate in case, e.g. add a verifier check where this breaks. I think it's a tradeoff anyway, I and Adrian discussed this briefly and agreed this is a decent middle ground (on one extreme, one might check ASM directly, but that seems even harder to handle). This is honestly based on my experience of having to regenerate broken bitcode files, happy to be convinced otherwise if you have arguments :) Repository: rLLDB LLDB https://reviews.llvm.org/D52678 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D52678: DWARFExpression: Resolve file addresses in the linked module
vsk added inline comments. Comment at: packages/Python/lldbsuite/test/functionalities/target_var/globals.ll:1 +source_filename = "globals.c" +target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128" davide wrote: > vsk wrote: > > Should we check in bitcode instead? That might make it easier to avoid > > breakage when the textual IR format changes. > But also will be more painful to regenerate in case, e.g. add a verifier > check where this breaks. > I think it's a tradeoff anyway, I and Adrian discussed this briefly and > agreed this is a decent middle ground (on one extreme, one might check ASM > directly, but that seems even harder to handle). > > This is honestly based on my experience of having to regenerate broken > bitcode files, happy to be convinced otherwise if you have arguments :) (per an off-list discussion) I'm slightly biased towards preventing build breaks, but this sounds reasonable. A third option might be to check in both the bitcode (which is compiled) and the IR (which serves as a reference for regenerating the bitcode); that could address all/most of the concerns. Repository: rLLDB LLDB https://reviews.llvm.org/D52678 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D50304: [lldb] CommandObjectThreadUntil should set breakpoint at either on exact or the nearest subsequent line number but not on all the subsequent line numbers
ramana-nvr added a comment. I do not have the commit permission. Could someone help commit this patch? https://reviews.llvm.org/D50304 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D50304: [lldb] CommandObjectThreadUntil should set breakpoint at either on exact or the nearest subsequent line number but not on all the subsequent line numbers
davide added a comment. I'll commit this for you, but I might ask if you can try adding a test first? https://reviews.llvm.org/D50304 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
