[Lldb-commits] [PATCH] D22851: [LLDB][MIPS] Add (D)SUBU, (D)ADDU, LUI instructions emulation . Fix emulation for (D)ADDIU, SD/SW and LW/LD instructions
nitesh.jain created this revision.
nitesh.jain added reviewers: jaydeep, bhushan, clayborg.
nitesh.jain added subscribers: slthakur, mohit.bhakkad, lldb-commits, sdardis.
Herald added a subscriber: dsanders.
To handle the immediate size greater than 2^16 - 1 , the clang compiler
generate LUI, (D)ADDIU, (D)SUBU sequence of instructions.
https://reviews.llvm.org/D22851
Files:
source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.cpp
source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.h
source/Plugins/Instruction/MIPS64/EmulateInstructionMIPS64.cpp
source/Plugins/Instruction/MIPS64/EmulateInstructionMIPS64.h
Index: source/Plugins/Instruction/MIPS64/EmulateInstructionMIPS64.h
===
--- source/Plugins/Instruction/MIPS64/EmulateInstructionMIPS64.h
+++ source/Plugins/Instruction/MIPS64/EmulateInstructionMIPS64.h
@@ -121,6 +121,12 @@
Emulate_DADDiu (llvm::MCInst& insn);
bool
+Emulate_DSUBU_DADDU (llvm::MCInst& insn);
+
+bool
+Emulate_LUI (llvm::MCInst& insn);
+
+bool
Emulate_SD (llvm::MCInst& insn);
bool
Index: source/Plugins/Instruction/MIPS64/EmulateInstructionMIPS64.cpp
===
--- source/Plugins/Instruction/MIPS64/EmulateInstructionMIPS64.cpp
+++ source/Plugins/Instruction/MIPS64/EmulateInstructionMIPS64.cpp
@@ -482,10 +482,15 @@
//--
// Prologue/Epilogue instructions
//--
-{ "DADDiu", &EmulateInstructionMIPS64::Emulate_DADDiu, "DADDIU rt,rs,immediate"},
-{ "ADDiu", &EmulateInstructionMIPS64::Emulate_DADDiu, "ADDIU rt,rs,immediate" },
-{ "SD", &EmulateInstructionMIPS64::Emulate_SD, "SD rt,offset(rs)" },
-{ "LD", &EmulateInstructionMIPS64::Emulate_LD, "LD rt,offset(base)"},
+{ "DADDiu", &EmulateInstructionMIPS64::Emulate_DADDiu, "DADDIU rt, rs, immediate"},
+{ "ADDiu", &EmulateInstructionMIPS64::Emulate_DADDiu, "ADDIU rt, rs, immediate"},
+{ "SD", &EmulateInstructionMIPS64::Emulate_SD, "SD rt, offset(rs)" },
+{ "LD", &EmulateInstructionMIPS64::Emulate_LD, "LD rt, offset(base)" },
+{ "DSUBU", &EmulateInstructionMIPS64::Emulate_DSUBU_DADDU, "DSUBU rd, rs, rt" },
+{ "SUBU", &EmulateInstructionMIPS64::Emulate_DSUBU_DADDU, "SUBU rd, rs, rt" },
+{ "DADDU", &EmulateInstructionMIPS64::Emulate_DSUBU_DADDU, "DADDU rd, rs, rt" },
+{ "ADDU", &EmulateInstructionMIPS64::Emulate_DSUBU_DADDU, "ADDU rd, rs, rt" },
+{ "LUI",&EmulateInstructionMIPS64::Emulate_LUI, "LUIrt, immediate"},
@@ -771,36 +776,57 @@
bool
EmulateInstructionMIPS64::Emulate_DADDiu (llvm::MCInst& insn)
{
+// DADDIU rt, rs, immediate
+// GPR[rt] <- GPR[rs] + sign_extend(immediate)
+
+uint8_t dst, src;
bool success = false;
const uint32_t imm16 = insn.getOperand(2).getImm();
-uint64_t imm = SignedBits(imm16, 15, 0);
-uint64_t result;
-uint32_t src, dst;
+int64_t imm = SignedBits(imm16, 15, 0);
dst = m_reg_info->getEncodingValue (insn.getOperand(0).getReg());
src = m_reg_info->getEncodingValue (insn.getOperand(1).getReg());
-/* Check if this is daddiu sp,,imm16 */
-if (dst == dwarf_sp_mips64)
+// If immediate is greater than 2^16 - 1 then clang generate
+// LUI, (D)ADDIU,(D)SUBU instructions in prolog.
+// Example
+// lui$1, 0x2
+// daddiu $1, $1, -0x5920
+// dsubu $sp, $sp, $1
+// In this case, (D)ADDIU dst and src will be same and not equal to sp
+if (dst == src)
{
+Context context;
+
/* read register */
-uint64_t src_opd_val = ReadRegisterUnsigned (eRegisterKindDWARF, dwarf_zero_mips64 + src, 0, &success);
+const int64_t src_opd_val = ReadRegisterUnsigned (eRegisterKindDWARF, dwarf_zero_mips64 + src, 0, &success);
if (!success)
return false;
-result = src_opd_val + imm;
+/* Check if this is daddiu sp, sp, imm16 */
+if (dst == dwarf_sp_mips64)
+{
+uint64_t result = src_opd_val + imm;
+RegisterInfo reg_info_sp;
-Context context;
-RegisterInfo reg_info_sp;
-if (GetRegisterInfo (eRegisterKindDWARF, dwarf_sp_mips64, reg_info_sp))
-context.SetRegisterPlusOffset (reg_info_sp, imm);
+if (GetRegisterInfo (eRegisterKindDWARF, dwarf_sp_mips64, reg_info_sp))
+context.SetRegisterPlusOffset (reg_info_sp, imm);
-/* We are allocating bytes on stack */
-context.type = eContextAdjustStack
Re: [Lldb-commits] [lldb] r276795 - Check both private & public states to decide if you need to halt before killing.
This fix is going to be flaky: Since the private state can flip back
and forth between running and stopped and there's no sychronization
between the private state thread and this code, you're going to get
unpredictable behavior depending on the exact moment you call
Destroy().
I assume the other thread is stuck in RunThreadPlan(), which does not
update the public state and that's why this does not fire. If that's
the case, we should check whether RunThreadPlan is active instead of
relying on the private state.
pl
On 26 July 2016 at 20:47, Jim Ingham via lldb-commits
wrote:
> Author: jingham
> Date: Tue Jul 26 14:47:45 2016
> New Revision: 276795
>
> URL: http://llvm.org/viewvc/llvm-project?rev=276795&view=rev
> Log:
> Check both private & public states to decide if you need to halt before
> killing.
>
> We were just checking the public state, but that meant if you were hung in a
> long
> running hand-called function, we wouldn't know to interrupt the process, and
> we would
> not succeed in killing it.
>
>
>
> Modified:
> lldb/trunk/source/Target/Process.cpp
>
> Modified: lldb/trunk/source/Target/Process.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/Process.cpp?rev=276795&r1=276794&r2=276795&view=diff
> ==
> --- lldb/trunk/source/Target/Process.cpp (original)
> +++ lldb/trunk/source/Target/Process.cpp Tue Jul 26 14:47:45 2016
> @@ -3634,7 +3634,10 @@ Error
> Process::StopForDestroyOrDetach(lldb::EventSP &exit_event_sp)
> {
> Error error;
> -if (m_public_state.GetValue() == eStateRunning)
> +
> +// Check both the public & private states here. If we're hung
> evaluating an expression, for instance, then
> +// the public state will be stopped, but we still need to interrupt.
> +if (m_public_state.GetValue() == eStateRunning ||
> m_private_state.GetValue() == eStateRunning)
> {
> Log *log(lldb_private::GetLogIfAllCategoriesSet
> (LIBLLDB_LOG_PROCESS));
> if (log)
>
>
> ___
> 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] Buildbot numbers for the week of 7/10/2016 - 7/16/2016
On Tue, Jul 26, 2016 at 8:14 PM, Galina Kistanova via cfe-commits wrote: > Hello everyone, > > Below are some buildbot numbers for the week of 7/10/2016 - 7/16/2016. > > Please see the same data in attached csv files: > > The longest time each builder was red during the week; > "Status change ratio" by active builder (percent of builds that changed the > builder status from greed to red or from red to green); > Count of commits by project; > Number of completed builds, failed builds and average build time for > successful builds per active builder; > Average waiting time for a revision to get build result per active builder > (response time); > > Thanks > > Galina > > > The longest time each builder was red during the last week: > > buildername| was_red > +--- > clang-sphinx-docs | 122:54:15 I am not certain that this builder is sending out emails when it goes red. Since this builds with warnings as errors, I think the builder should be sending out notifications so we hopefully don't run into this again. Any warning means we leave outdated documentation on the public website. Either that, or we should disable treating warnings as errors (which I don't think is a good idea, and would prefer to avoid). Same goes for the other sphinx bots (llvm & lld were both red this week, repeatedly, as well). ~Aaron > sanitizer-x86_64-linux-fuzzer | 58:12:52 > perf-x86_64-penryn-O3-polly-before-vectorizer | 39:52:18 > clang-native-aarch64-full | 31:59:05 > sanitizer-x86_64-linux-bootstrap | 27:37:36 > perf-x86_64-penryn-O3-polly-before-vectorizer-unprofitable | 25:34:19 > clang-cmake-armv7-a15-selfhost | 24:00:48 > clang-x86_64-linux-selfhost-modules| 23:57:52 > polly-amd64-linux | 23:29:30 > clang-cmake-thumbv7-a15-full-sh| 23:23:52 > lldb-windows7-android | 22:15:39 > clang-cmake-aarch64-quick | 21:54:32 > clang-3stage-ubuntu| 21:39:52 > clang-x86-win2008-selfhost | 19:02:47 > perf-x86_64-penryn-O3-polly-unprofitable | 18:50:41 > perf-x86_64-penryn-O3 | 18:03:53 > clang-x64-ninja-win7 | 17:19:40 > lldb-x86_64-ubuntu-14.04-android | 17:09:21 > clang-cmake-armv7-a15-selfhost-neon| 16:35:10 > perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only | 16:34:08 > clang-cmake-aarch64-full | 16:11:16 > clang-native-arm-lnt | 16:00:43 > lldb-x86_64-ubuntu-14.04-cmake | 13:02:12 > clang-ppc64be-linux-multistage | 11:36:28 > sanitizer-x86_64-linux-fast| 10:24:56 > perf-x86_64-penryn-O3-polly-fast | 10:22:11 > sanitizer-x86_64-linux | 09:52:43 > clang-cmake-mipsel | 09:38:52 > clang-atom-d525-fedora-rel | 09:33:56 > perf-x86_64-penryn-O3-polly| 08:11:16 > clang-ppc64le-linux-multistage | 06:07:25 > sanitizer-ppc64le-linux| 04:21:05 > llvm-clang-lld-x86_64-debian-fast | 04:16:01 > clang-cuda-build | 04:13:46 > clang-x86_64-debian-fast | 04:11:41 > llvm-mips-linux| 04:01:44 > llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast | 04:01:03 > clang-ppc64le-linux-lnt| 04:00:27 > clang-s390x-linux | 03:50:24 > clang-ppc64be-linux| 03:46:53 > clang-ppc64be-linux-lnt| 03:46:29 > perf-x86_64-penryn-O3-polly-parallel-fast | 03:46:14 > lld-x86_64-freebsd | 03:39:34 > sanitizer-windows | 03:32:27 > lld-x86_64-darwin13| 03:27:07 > llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast | 03:23:57 > lld-x86_64-win7| 03:22:32 > clang-cmake-aarch64-42vma | 03:20:10 > clang-ppc64le-linux| 03:00:31 > clang-
Re: [Lldb-commits] [lldb] r276795 - Check both private & public states to decide if you need to halt before killing.
If you go to halt a thread whose private state is running, and by the time you
get to halting it the private state has gone from running to stopped then the
code doing the halt will declare victory, since that's what it was trying to
do. If it was still running, then it will have to interrupt. I don't see how
this will be flakey.
Jim
> On Jul 27, 2016, at 5:09 AM, Pavel Labath wrote:
>
> This fix is going to be flaky: Since the private state can flip back
> and forth between running and stopped and there's no sychronization
> between the private state thread and this code, you're going to get
> unpredictable behavior depending on the exact moment you call
> Destroy().
>
> I assume the other thread is stuck in RunThreadPlan(), which does not
> update the public state and that's why this does not fire. If that's
> the case, we should check whether RunThreadPlan is active instead of
> relying on the private state.
>
> pl
>
> On 26 July 2016 at 20:47, Jim Ingham via lldb-commits
> wrote:
>> Author: jingham
>> Date: Tue Jul 26 14:47:45 2016
>> New Revision: 276795
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=276795&view=rev
>> Log:
>> Check both private & public states to decide if you need to halt before
>> killing.
>>
>> We were just checking the public state, but that meant if you were hung in a
>> long
>> running hand-called function, we wouldn't know to interrupt the process, and
>> we would
>> not succeed in killing it.
>>
>>
>>
>> Modified:
>>lldb/trunk/source/Target/Process.cpp
>>
>> Modified: lldb/trunk/source/Target/Process.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/Process.cpp?rev=276795&r1=276794&r2=276795&view=diff
>> ==
>> --- lldb/trunk/source/Target/Process.cpp (original)
>> +++ lldb/trunk/source/Target/Process.cpp Tue Jul 26 14:47:45 2016
>> @@ -3634,7 +3634,10 @@ Error
>> Process::StopForDestroyOrDetach(lldb::EventSP &exit_event_sp)
>> {
>> Error error;
>> -if (m_public_state.GetValue() == eStateRunning)
>> +
>> +// Check both the public & private states here. If we're hung
>> evaluating an expression, for instance, then
>> +// the public state will be stopped, but we still need to interrupt.
>> +if (m_public_state.GetValue() == eStateRunning ||
>> m_private_state.GetValue() == eStateRunning)
>> {
>> Log *log(lldb_private::GetLogIfAllCategoriesSet
>> (LIBLLDB_LOG_PROCESS));
>> if (log)
>>
>>
>> ___
>> 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] [lldb] r276795 - Check both private & public states to decide if you need to halt before killing.
On 27 July 2016 at 17:41, Jim Ingham wrote: > If you go to halt a thread whose private state is running, and by the time > you get to halting it the private state has gone from running to stopped then > the code doing the halt will declare victory, since that's what it was trying > to do. If it was still running, then it will have to interrupt. I don't see > how this will be flakey. > This case is fine. The tricky part is the opposite: - we check the private state, see that it is stopped and decide that we have nothing to do - meanwhile, the private state flips back to running (e.g. because it was just temporarily stopped while it was stepping over a breakpoint) - RunThreadPlan carries on running oblivious to the fact that someone tried to interrupt it - process does not stop pl ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22831: [LLDB] Documentation for SBAddress class
clayborg requested changes to this revision. clayborg added a comment. This revision now requires changes to proceed. A few modifications to the SBAddress info Comment at: include/lldb/API/SBAddress.h:32 @@ +31,3 @@ +/// target. +/// +/// The individual Get*() functions grab individual objects for a given Maybe start off with something like: ``` If an address has a valid section, the address might refer to things found in the debug information: SBModule - the module that contains the section SBCompileUnit - the source file that was compiled to create this code SBFunction - the function that contains this address SBBlock - the deepest lexical block that contains the address within the SBFucntion SBLineEntry - the file and line and column that contains the address SBVariable - the static/global variable that contains the address If there is no debug information, then the address might also refer to a symbol from the symbol table: SBSymbol - the symbol that contains the address ``` Comment at: include/lldb/API/SBAddress.h:44 @@ -18,1 +43,3 @@ +/// objects. +//-- class LLDB_API SBAddress We should add a blurb about "file addresses" and "load addresses" to explain what they are. Maybe something like: ``` SBAddress objects can vend two types of addresses: file address and load address. File addresses refer to the raw address as it is known in the object file that the module is using. File addresses will match the virtual addresses that are found in the object file, such as the address values in the symbols in the native symbol tables, unwind tables and any other data structures in the object file format (ELF, mach-o, COFF). File addresses are not unique across multiple modules as many modules might contain a file address of 0x0 (possibly the first function in the .text section) since many object files, like shared libraries, have their virtual addresses start at 0x0. Load addresses represent a unique location within a process' address space. A load address might represent a section/offset address within a process. In this case the SBAddress will have a valid section (lldb::SBAddress::GetSection() will return a SBSection that is valid), and a valid offset (lldb::addr_t lldb::SBAddress::GetOffset()) into that section. Or a load address might represent a unique location in the process' memory space that doesn't resolve to a section within an object file, like a location on the stack or heap. In this case the address will not have a valid section (lldb::SBSection lldb::SBAddress::GetSection() will return a SBSection that is *not* valid), and lldb::SBAddress::GetOffset() will return the value load address. ``` Comment at: include/lldb/API/SBAddress.h:117 @@ +116,3 @@ +/// fails, assumes the address is absolute, e.g., on the stack or heap. +/// The object becomes valid. +/// This is incorrect. The object will be valid, but will contain no section, and the offset will match the load address. Comment at: include/lldb/API/SBAddress.h:148 @@ +147,3 @@ +//-- +/// Lookup symbol information for this address. +/// // Lookup debug and symbol information that contains this address Comment at: include/lldb/API/SBAddress.h:159 @@ -68,11 +158,3 @@ - -// The following functions grab individual objects for a given address and -// are less efficient if you want more than one symbol related objects. -// Use one of the following when you want multiple debug symbol related -// objects for an address: -//lldb::SBSymbolContext SBAddress::GetSymbolContext (uint32_t resolve_scope); -//lldb::SBSymbolContext SBTarget::ResolveSymbolContextForAddress (const SBAddress &addr, uint32_t resolve_scope); -// One or more bits from the SymbolContextItem enumerations can be logically -// OR'ed together to more efficiently retrieve multiple symbol objects. - +//-- +/// @return // Get the section, if any, that this address refers to Comment at: include/lldb/API/SBAddress.h:166 @@ -81,1 +165,3 @@ +//-- +/// @return // Get the offset for this address // // If this address contains a section, this value is the offset within that section. // If the address doesn't have a valid section, then this address refers to an // absolute address Comment at: include/lldb/API/SBAddress.h:173 @@ -84,1 +172,3 @@ +//-- +/// @return // Get the module that contains this address // // The
Re: [Lldb-commits] [PATCH] D22629: Rewrite gdb-remote's SendContinuePacketAndWaitForResponse
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
This provides a clearer implementation of our async code that grew over the
years and was bolted on, thanks for digging into this.
Looks good a few changes, see inlined comments.
I have some reservations about your future changes to add concurrent packets.
We should discuss this at length before you try to make any changes on the
mailing list.
Comment at: source/Plugins/Process/gdb-remote/GDBRemoteClientBase.cpp:57
@@ +56,3 @@
+std::lock_guard lock(m_mutex);
+if (m_async_count == 0)
+continue;
if you add an assert, please use lldbassert
Comment at: source/Plugins/Process/gdb-remote/GDBRemoteClientBase.cpp:148-150
@@ +147,5 @@
+Lock lock(*this, true);
+if (lock.DidInterrupt())
+m_should_stop = true;
+return lock.DidInterrupt();
+}
Do we need to call lock.DidInterrupt() twice?
Comment at: source/Plugins/Process/gdb-remote/GDBRemoteClientBase.cpp:261-268
@@ +260,10 @@
+std::string inferior_stdout;
+inferior_stdout.reserve(packet.GetBytesLeft() / 2);
+
+uint8_t ch;
+while (packet.GetHexU8Ex(ch))
+{
+if (ch != 0)
+inferior_stdout.append(1, (char)ch);
+}
+delegate.HandleAsyncStdout(inferior_stdout);
We can probably switch over using a new function that was added after this code
was created:
```
size_t
StringExtractor::GetHexByteString (std::string &str);
```
So this could be:
```
inferior_stdout.reserve(packet.GetBytesLeft() / 2);
packet. GetHexByteString(inferior_stdout.reserve);
```
Comment at: source/Plugins/Process/gdb-remote/GDBRemoteClientBase.h:28-29
@@ +27,4 @@
+virtual ~ContinueDelegate();
+virtual void
+HandleAsyncStdout(llvm::StringRef out) = 0;
+virtual void
Why not just use "const std::string &" here instead of llvm::StringRef? It is
OK to use std::string in internal APIs and llvm::StringRef buys us nothing.
Comment at: source/Plugins/Process/gdb-remote/GDBRemoteClientBase.h:31
@@ +30,3 @@
+virtual void
+HandleAsyncMisc(llvm::StringRef data) = 0;
+virtual void
Why not just use "const std::string &" here instead of llvm::StringRef? It is
OK to use std::string in internal APIs and llvm::StringRef buys us nothing.
https://reviews.llvm.org/D22629
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22863: Improve code of loading plugins that provide cmnds
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
You can't change the exiting public API (anything in include/lldb/API/*). If
you want to a add a new function, you must add a new version with the new
argument, but leave the old one alone. See the following link for details:
http://lldb.llvm.org/architecture/index.html#api
SBCommandPluginInterface is special because it does have virtual functions.
This means you can't change it or any of the virtual functions. So all changes
to this class must be reverted since old code might have linked against the old
version and still be compiled for the old version.
A simpler fix for all of this could be to just add a:
lldb::SBCommand::SetSyntax(const char *);
Then you wouldn't need to modify any other classes. But you can add new
variants that include syntax to the AddCommand() function if you want.
Comment at: include/lldb/API/SBCommandInterpreter.h:141-142
@@ -140,4 +140,4 @@
lldb::SBCommand
-AddCommand (const char* name, lldb::SBCommandPluginInterface *impl, const
char* help);
+AddCommand (const char* name, lldb::SBCommandPluginInterface *impl, const
char* help, const char* syntax);
You can't change public API, you can only add to it. Just add another function
with syntax and leave the other one alone.
Comment at: include/lldb/API/SBCommandInterpreter.h:270
@@ -269,2 +269,3 @@
char** /*command*/,
+ size_t /*number of arguments*/,
lldb::SBCommandReturnObject & /*result*/)
Since this is a special class that does use virtual functions that is in the
public API, you can't change it. Previous code might have linked against the
LLDB shared library and changing this would break those plug-ins and they would
install their new implementation in the vtable slot for this function and it
would be called incorrectly. Revert this change.
Comment at: include/lldb/API/SBCommandInterpreter.h:310
@@ -308,3 +309,3 @@
lldb::SBCommand
-AddCommand(const char* name, lldb::SBCommandPluginInterface* impl, const
char* help = nullptr);
+AddCommand(const char* name, lldb::SBCommandPluginInterface* impl, const
char* help = nullptr, const char* syntax = nullptr);
You can't change public API, you can only add to it. Just add another function
with syntax and leave the other one alone.
Comment at:
packages/Python/lldbsuite/test/functionalities/plugins/commands/plugin.cpp:37
@@ -36,2 +36,3 @@
char** command,
+ size_t arg_count,
lldb::SBCommandReturnObject &result)
revert
Comment at: source/API/SBCommandInterpreter.cpp:152
@@ -151,3 +151,3 @@
SBDebugger debugger_sb(m_interpreter.GetDebugger().shared_from_this());
-bool ret = m_backend->DoExecute
(debugger_sb,(char**)command.GetArgumentVector(), sb_return);
+bool ret = m_backend->DoExecute
(debugger_sb,(char**)command.GetArgumentVector(),command.GetArgumentCount(),
sb_return);
sb_return.Release();
Remove count, revert this line.
Comment at: source/API/SBCommandInterpreter.cpp:156
@@ -155,3 +155,3 @@
}
-lldb::SBCommandPluginInterface* m_backend;
+std::shared_ptr m_backend;
};
Can't change public API, revert this. This would break anyone's existing
commands as the layout of this class would change and possibly break and code
that links against this.
Comment at: source/API/SBCommandInterpreter.cpp:598
@@ -597,3 +597,3 @@
lldb::SBCommand
-SBCommandInterpreter::AddCommand (const char* name,
lldb::SBCommandPluginInterface* impl, const char* help)
+SBCommandInterpreter::AddCommand (const char* name,
lldb::SBCommandPluginInterface* impl, const char* help, const char* syntax)
{
You can't change public API, you can only add to it. Just add another function
with syntax and leave the other one alone.
Comment at: source/API/SBCommandInterpreter.cpp:667
@@ -666,3 +666,3 @@
lldb::SBCommand
-SBCommand::AddCommand (const char* name, lldb::SBCommandPluginInterface *impl,
const char* help)
+SBCommand::AddCommand (const char* name, lldb::SBCommandPluginInterface *impl,
const char* help, const char* syntax)
{
You can't change public API, you can only add to it. Just add another function
with syntax and leave the other one alone.
https://reviews.llvm.org/D22863
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r276914 - Fixed "void SBWatchpoint::SetEnabled (bool enabled)" to work properly and added a test for it.
Author: gclayton
Date: Wed Jul 27 15:47:49 2016
New Revision: 276914
URL: http://llvm.org/viewvc/llvm-project?rev=276914&view=rev
Log:
Fixed "void SBWatchpoint::SetEnabled (bool enabled)" to work properly and added
a test for it.
https://llvm.org/bugs/show_bug.cgi?id=28729
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_events/TestWatchpointEvents.py
lldb/trunk/source/API/SBWatchpoint.cpp
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_events/TestWatchpointEvents.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_events/TestWatchpointEvents.py?rev=276914&r1=276913&r2=276914&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_events/TestWatchpointEvents.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_events/TestWatchpointEvents.py
Wed Jul 27 15:47:49 2016
@@ -64,17 +64,23 @@ class TestWatchpointEvents (TestBase):
if not error.Success():
self.fail ("Failed to make watchpoint for local_var:
%s"%(error.GetCString()))
-self.GetWatchpointEvent (lldb.eWatchpointEventTypeAdded)
+self.GetWatchpointEvent(lldb.eWatchpointEventTypeAdded)
# Now change some of the features of this watchpoint and make sure we
get events:
local_watch.SetEnabled(False)
-self.GetWatchpointEvent (lldb.eWatchpointEventTypeDisabled)
+self.GetWatchpointEvent(lldb.eWatchpointEventTypeDisabled)
+
+local_watch.SetEnabled(True)
+self.GetWatchpointEvent(lldb.eWatchpointEventTypeEnabled)
local_watch.SetIgnoreCount(10)
-self.GetWatchpointEvent (lldb.eWatchpointEventTypeIgnoreChanged)
+self.GetWatchpointEvent(lldb.eWatchpointEventTypeIgnoreChanged)
-local_watch.SetCondition ("1 == 2")
-self.GetWatchpointEvent (lldb.eWatchpointEventTypeConditionChanged)
+condition = "1 == 2"
+local_watch.SetCondition(condition)
+self.GetWatchpointEvent(lldb.eWatchpointEventTypeConditionChanged)
+self.assertTrue(local_watch.GetCondition() == condition, 'make sure
watchpoint condition is "' + condition + '"');
+
def GetWatchpointEvent (self, event_type):
# We added a watchpoint so we should get a watchpoint added event.
event = lldb.SBEvent()
Modified: lldb/trunk/source/API/SBWatchpoint.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/API/SBWatchpoint.cpp?rev=276914&r1=276913&r2=276914&view=diff
==
--- lldb/trunk/source/API/SBWatchpoint.cpp (original)
+++ lldb/trunk/source/API/SBWatchpoint.cpp Wed Jul 27 15:47:49 2016
@@ -159,7 +159,7 @@ SBWatchpoint::SetEnabled (bool enabled)
if (watchpoint_sp)
{
std::lock_guard
guard(watchpoint_sp->GetTarget().GetAPIMutex());
-
watchpoint_sp->GetTarget().DisableWatchpointByID(watchpoint_sp->GetID());
+watchpoint_sp->SetEnabled(enabled);
}
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22863: Improve code of loading plugins that provide cmnds
granata.enrico added a comment. Everything Greg said makes total sense In general dynamically loadable C++ plugins as a feature is a little rough around the edges. I am glad to see interest in improving it! https://reviews.llvm.org/D22863 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r276795 - Check both private & public states to decide if you need to halt before killing.
> On Jul 27, 2016, at 10:08 AM, Pavel Labath wrote: > > On 27 July 2016 at 17:41, Jim Ingham wrote: >> If you go to halt a thread whose private state is running, and by the time >> you get to halting it the private state has gone from running to stopped >> then the code doing the halt will declare victory, since that's what it was >> trying to do. If it was still running, then it will have to interrupt. I >> don't see how this will be flakey. >> > > This case is fine. The tricky part is the opposite: > - we check the private state, see that it is stopped and decide that > we have nothing to do > - meanwhile, the private state flips back to running (e.g. because it > was just temporarily stopped while it was stepping over a breakpoint) > - RunThreadPlan carries on running oblivious to the fact that someone > tried to interrupt it > - process does not stop Yes, I see. This change always checks public state running, so all the flips from run to stopped in the private state thread will have no effect on all the modes of running except expression evaluation. The change as is is better than what was there before, even though it doesn't handle this case. This check will fix the case where you have an expression that stalls and you go to kill the process (you have to be using a UI to do this, since otherwise you'd have to interrupt the expression to type "kill".) Before this change, Destroy would do nothing in this case. That's much more common than happening to be in the I have other things on my plate right now, but I filed: https://llvm.org/bugs/show_bug.cgi?id=28742 to remind myself to go back and make this better. Jim ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D22891: Remove a duplicated block in cmake.
sas created this revision.
sas added a reviewer: tfiala.
sas added a subscriber: lldb-commits.
This is supposed to find the python lib dir and seems like it's just
been copied twice by mistake.
https://reviews.llvm.org/D22891
Files:
source/Host/CMakeLists.txt
Index: source/Host/CMakeLists.txt
===
--- source/Host/CMakeLists.txt
+++ source/Host/CMakeLists.txt
@@ -163,19 +163,6 @@
endif()
endif()
-if (${get_python_libdir})
- # Call a python script to gather the arch-specific libdir for
- # modules like the lldb module.
- execute_process(
-COMMAND ${PYTHON_EXECUTABLE}
${CMAKE_CURRENT_SOURCE_DIR}/../../scripts/get_relative_lib_dir.py
-RESULT_VARIABLE get_libdir_status
-OUTPUT_VARIABLE relative_libdir
-)
- if (get_libdir_status EQUAL 0)
-add_definitions(-DLLDB_PYTHON_RELATIVE_LIBDIR="${relative_libdir}")
- endif()
-endif()
-
add_lldb_library(lldbHost ${HOST_SOURCES})
if (CMAKE_SYSTEM_NAME MATCHES "NetBSD")
Index: source/Host/CMakeLists.txt
===
--- source/Host/CMakeLists.txt
+++ source/Host/CMakeLists.txt
@@ -163,19 +163,6 @@
endif()
endif()
-if (${get_python_libdir})
- # Call a python script to gather the arch-specific libdir for
- # modules like the lldb module.
- execute_process(
-COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/../../scripts/get_relative_lib_dir.py
-RESULT_VARIABLE get_libdir_status
-OUTPUT_VARIABLE relative_libdir
-)
- if (get_libdir_status EQUAL 0)
-add_definitions(-DLLDB_PYTHON_RELATIVE_LIBDIR="${relative_libdir}")
- endif()
-endif()
-
add_lldb_library(lldbHost ${HOST_SOURCES})
if (CMAKE_SYSTEM_NAME MATCHES "NetBSD")
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22891: Remove a duplicated block in cmake.
tfiala accepted this revision. tfiala added a comment. This revision is now accepted and ready to land. Yeah, that looks like a merge issue of some sort. https://reviews.llvm.org/D22891 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22851: [LLDB][MIPS] Add (D)SUBU, (D)ADDU, LUI instructions emulation . Fix emulation for (D)ADDIU, SD/SW and LW/LD instructions
bhushan accepted this revision. bhushan added a comment. LGTM https://reviews.llvm.org/D22851 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r276954 - Add some logging to the kernel dynamicloader plugin when we fail to read
Author: jmolenda
Date: Wed Jul 27 23:18:44 2016
New Revision: 276954
URL: http://llvm.org/viewvc/llvm-project?rev=276954&view=rev
Log:
Add some logging to the kernel dynamicloader plugin when we fail to read
a kext binary from memory.
Modified:
lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
Modified:
lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp?rev=276954&r1=276953&r2=276954&view=diff
==
---
lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
(original)
+++
lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
Wed Jul 27 23:18:44 2016
@@ -774,6 +774,9 @@ DynamicLoaderDarwinKernel::KextImageInfo
// have the correct segment load addresses.
if (!ReadMemoryModule (process))
{
+Log *log(GetLogIfAnyCategoriesSet (LIBLLDB_LOG_DYNAMIC_LOADER));
+if (log)
+log->Printf("Unable to read '%s' from memory at address 0x%"
PRIx64 " to get the segment load addresses.", m_name.c_str(), m_load_address);
return false;
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] Fix -break-insert not working when using absolute paths
When trying to parse the -break-insert arguments as a named location, the string parsing was not configured to allow directory paths. This patch adds a constructor to allow the parsing of string as directory path along with the other parameters. This fixes https://llvm.org/bugs/show_bug.cgi?id=28709 bug28709.patch Description: Binary data ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] Fix -break-insert not working when using absolute paths
When trying to parse the -break-insert arguments as a named location, the string parsing was not configured to allow directory paths. This patch adds a constructor to allow the parsing of string as directory path along with the other parameters. This fixes https://llvm.org/bugs/show_bug.cgi?id=28709 bug28709.patch Description: Binary data ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22902: Fix -break-insert not working when using absolute paths
ki.stfu added a comment. Could you add a test case for this in packages/Python/lldbsuite/test/tools/lldb-mi/breakpoint/TestMiBreak.py? https://reviews.llvm.org/D22902 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
