Simple "file" might not be enough for Eclipse CDT to find the file, therefore it is preferable for -data-disassemble response to include full absolute file path in the "fullname" field, similarly to how it is implemented in the CMICmnLLDBDebugSessionInfo::GetFrameInfo() function.
Details
- Reviewers
ki.stfu deepak2427 abidh clayborg - Commits
- rZORG788bb8ab8a15: [lldb-mi] Include full path in the -data-disassemble response
rG788bb8ab8a15: [lldb-mi] Include full path in the -data-disassemble response
rGe0cc56e038df: [lldb-mi] Include full path in the -data-disassemble response
rLLDB361255: [lldb-mi] Include full path in the -data-disassemble response
rL361255: [lldb-mi] Include full path in the -data-disassemble response
Diff Detail
- Repository
- rL LLVM
Event Timeline
lldb/tools/lldb-mi/MICmdCmdData.cpp | ||
---|---|---|
419 ↗ | (On Diff #193863) | This shouldn't be static. Probably not going to cause problems if this is always single threaded, but still you should fix this. |
Replaced static local variable (as can be found in CMICmnLLDBDebugSessionInfo::GetFrameInfo) with a unique_ptr to the char array (as done in CMICmnLLDBDebuggerHandleEvents::MiHelpGetModuleInfo).
lldb/tools/lldb-mi/MICmdCmdData.cpp | ||
---|---|---|
420 ↗ | (On Diff #194376) | There is a variant of FileSpec::GetPath() that returns a std::string: std::string path = lineEntry.GetFileSpec().GetPath(); Then you can get rid of the code above: std::unique_ptr<char[]> pPathBuffer(new char[PATH_MAX]); |
lldb/tools/lldb-mi/MICmdCmdData.cpp | ||
---|---|---|
420 ↗ | (On Diff #194376) | LLDB MI uses SBFileSpec rather then FileSpec, and SBFileSpec doesn't have such a function. |
lldb/tools/lldb-mi/MICmdCmdData.cpp | ||
---|---|---|
419 ↗ | (On Diff #194376) | Confused as to why we are calling malloc and free here for pPathBuffer? Why not just: char pPathBuffer[PATH_MAX]; |
lldb/tools/lldb-mi/MICmdCmdData.cpp | ||
---|---|---|
419 ↗ | (On Diff #194376) | I don't have a strong opinion on this, so to maintain consistency in the code I'm trying to use what other code in lldb-mi uses in similar situations - which is either unique_ptr or static local variable, but I presume it was decided that second approach is not good. FWIW, If I were to write code without regard of what is being done in the same project, then I would never ever had a variable named "miValueConst5". |
lldb/tools/lldb-mi/MICmdCmdData.cpp | ||
---|---|---|
419 ↗ | (On Diff #194376) | I would just use a local variable on the stack as I suggested. static variables are not correct and should never be used in cases like this, so if you see other errors, might be a good idea to submit a patch and improve lldb-mi. I am all for consistency where it makes sense, but I am also for fixing issues when we see them. |
lldb/tools/lldb-mi/MICmdCmdData.cpp | ||
---|---|---|
419 ↗ | (On Diff #194376) | But what is wrong with the approach of using std::unique_ptr<char[]> local variable? |
lldb/tools/lldb-mi/MICmdCmdData.cpp | ||
---|---|---|
419 ↗ | (On Diff #194376) | That forces a call to malloc(...) and free(...). No need to involve allocations on the heap for such simple things |
LGTM. If there are any other " std::unique_ptr<char[]>" instances you would like to fix after this patch, feel free to submit more fixes without need for review.