This is an archive of the discontinued LLVM Phabricator instance.

[lldb, lldb-mi] Re-implement MI -exec-continue command.
ClosedPublic

Authored by polyakov.alex on May 26 2018, 11:22 AM.

Diff Detail

Repository
rL LLVM

Event Timeline

polyakov.alex created this revision.May 26 2018, 11:22 AM
polyakov.alex edited the summary of this revision. (Show Details)May 26 2018, 11:23 AM
clayborg accepted this revision.May 29 2018, 9:18 AM

So nice to get rid of these HandleCommand hacks!

This revision is now accepted and ready to land.May 29 2018, 9:18 AM

Updated because of commited -exec-next and -exec-step commands.

clayborg added inline comments.Jun 7 2018, 1:25 PM
tools/lldb-mi/MICmdCmdExec.cpp
234–235

An error can claim to fail but not have an error string set. It might be nice to have a helper function that checks to make sure there is an error string on error cases and if there is no error string when error.Success() is false or error.Fail() is true, then set the error string to "unknown error".

polyakov.alex added inline comments.Jun 7 2018, 1:40 PM
tools/lldb-mi/MICmdCmdExec.cpp
234–235

This functionality might be useful in all lldb-mi commands. So do you know where to place this function? Maybe inside SBError class?

clayborg added inline comments.Jun 7 2018, 1:47 PM
tools/lldb-mi/MICmdCmdExec.cpp
234–235

I would put it somewhere in lldb-mi in a static function that is something like:

static void SetErrorString(lldb::SBError &error, T &lldbResult) {
  const char *error_cstr = error.GetCString();
  if (error_cstr)
    lldbResult.SetError(error.GetCString());
  else
    lldbResult.SetError("unknown error");
}

Where the T is the type of m_lldbResult.

clayborg added inline comments.Jun 7 2018, 1:58 PM
tools/lldb-mi/MICmdCmdExec.cpp
234–235

Actually, are we using m_lldbResult now? I didn't realize its type was lldb::SBCommandReturnObject. That was only needed if we were calling:

rSessionInfo.GetDebugger().GetCommandInterpreter().HandleCommand(pCmd, m_lldbResult);

So we can get rid of all "lldb::SBCommandReturnObject m_lldbResult" member variables in any lldb-mi functions where we switch to using the API.

clayborg requested changes to this revision.Jun 7 2018, 2:00 PM

Also need to remove m_lldbResult from the CMICmdCmdExecContinue class.

tools/lldb-mi/MICmdCmdExec.cpp
234–235

Since we can get rid of m_lldbResult, this should be:

} else return MIstatus::failure;
This revision now requires changes to proceed.Jun 7 2018, 2:00 PM
polyakov.alex added inline comments.Jun 7 2018, 2:14 PM
tools/lldb-mi/MICmdCmdExec.cpp
234–235

It should be:

else {
  SetError(CMIUtilString::Format(..., error.GetCString()));
  return MIstatus::failure;
}

So, we anyway need a C-style error string.

labath added a subscriber: labath.Jun 8 2018, 1:19 AM
labath added inline comments.
tools/lldb-mi/MICmdCmdExec.cpp
234–235

AFAICT, SBError::GetCString calls Status::AsCString which has a default argument const char *default_error_str = "unknown error". So it sounds like this issue is already taken care of down below. If we are still getting null strings for failed SBErrors, maybe we need to fix something else instead of adding another layer here.

apolyakov added inline comments.
tools/lldb-mi/MICmdCmdExec.cpp
234–235

SBError::GetCString potentially may return NULL:

const char *SBError::GetCString() const {
  if (m_opaque_ap.get())
    return m_opaque_ap->AsCString();
  return NULL;
}
labath added inline comments.Jun 8 2018, 2:32 AM
tools/lldb-mi/MICmdCmdExec.cpp
234–235

Yes, but that can happen only in case SBError::Fail() is false, which means you probably shouldn't be calling GetCString in the first place.

polyakov.alex added a reviewer: labath.

Removed unnecessary m_lldbResult attribute.

clayborg accepted this revision.Jun 8 2018, 9:14 AM
This revision is now accepted and ready to land.Jun 8 2018, 9:14 AM
This revision was automatically updated to reflect the committed changes.