[Lldb-commits] [PATCH] Fix handling of CommandInterpreter's events in lldb-mi

[Ilia K]

@clayborg, see below:


================
Comment at: source/API/SBCommandInterpreter.cpp:554
@@ +553,3 @@
+{
+    return strcmp (event.GetBroadcasterClass(), SBCommandInterpreter::GetBroadcasterClass()) == 0;
+}
----------------
clayborg wrote:
> The strings are returns as the "const char *" from a lldb_private::ConstString object, so just do a pointer compare instead of a strcmp.
I think it's wrong.
```
file1.cpp:

const char s1 [] = "abc";
```

```
file2.cpp:

extern const char s1 [];
const char *s2 = "abc";
assert (s1==s2); // error
assert (!strcmp (s1,s2)); // ok
```

I'd prefer to keep it as is.

================
Comment at: tools/lldb-mi/MICmnLLDBDebugger.cpp:300
@@ -299,2 +299,3 @@
     bOk = bOk && RegisterForEvent(strDbgId, CMIUtilString(lldb::SBCommandInterpreter::GetBroadcasterClass()), eventMask);
+    m_lldbDebugger.GetCommandInterpreter().GetBroadcaster().CheckInWithManager();
 
----------------
clayborg wrote:
> ki.stfu wrote:
> > abidh wrote:
> > > Why we have to do this for command interpreter? 
> > Because CommandInterpreter object already has been created in contrast to Target/Thread/Process.
> You shouldn't have to do this, it is being done in the lldb_private::CommandInterpreter::CommandInterpreter(). How did you manage to not contract a CommandInterpreter and yet you are able to listen to events from it?
>RE: You shouldn't have to do this, it is being done in the lldb_private::CommandInterpreter::CommandInterpreter().
But I have a problem:
# CMICmnLLDBDebugger::InitSBListener() registers events (which are needed for lldb-mi) using the SBListener::StartListeningForEventClass().
# SBListener::StartListeningForEventClass() is used for classes that weren't created (otherwise the SBBroadcast::CheckInWithManager() should be called).
# In this situation, we register events (using SBListener::StartListeningForEventClass()) for already created class SBCommandInterpreter. I can't register events before this class is created because it is done simultaneously with SBDebugger (which is used in SBListener::StartListeningForEventClass()).

I assume we can use SBListener::StartListeningForEventClass() for SBTarget/SBProcess/SBThread and SBListener::StartListeningForEvents() for SBCommandInterpreter but I'm not sure that it's right solution.

Do we have any restrictions to use SBListener::StartListeningForEventClass()?

>RE: How did you manage to not contract a CommandInterpreter and yet you are able to listen to events from it?
Previously lldb-mi ignored all CommandInterpreter's events.

http://reviews.llvm.org/D8382

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/