This fixes -data-info-line and -symbol-list-lines to parse the filename and line correctly when line entries don't have the optional column number and the filename contains a Windows drive letter. It also fixes -symbol-list-lines when code from header files is generated.
Details
- Reviewers
abidh ki.stfu brucem - Commits
- rGb01310008ff7: [lldb-mi] Fix the handling of files in -data-info-line and -symbol-list-lines.
rLLDB247899: [lldb-mi] Fix the handling of files in -data-info-line and -symbol-list-lines.
rL247899: [lldb-mi] Fix the handling of files in -data-info-line and -symbol-list-lines.
Diff Detail
- Repository
- rL LLVM
Event Timeline
Rather than all of this ugly error-prone code, can we instead use
llvm::sys::fs::root_name to check whether the path contains a drive letter?
Sadly no, because root_name only parses c:\ correctly if the platform is Windows. Our IDE is hosted on Windows but talks to lldb running on OSX. I've had this path problem with the DWARF reader and FileSpec - lldb has a core assumption that you only want to support Windows paths if you run on Windows. At least with FileSpec you can pass a PathSyntax, but you have to choose either Windows or Posix, not both. We want to support both Posix and Windows style paths. I've not come up with a clean patch for this problem so none have been submitted. We should start another thread about how to resolve this problem...
For now, would it be OK to put a FIXME comment in the source?
Are you saying that there is a situation where you are given a path, and
you have no idea whether it is a posix path or a windows path? That seems
strange to me. Surely you must know (or be able to find out) if the
computer you are interfacing with is running Windows or non-Windows, right?
Are you saying that there is a situation where you are given a path, and you have no idea whether it is a posix path or a windows path?
Yes. For example, in lldb on OSX, we can be debugging an app that was built on OSX, or an app that was built on Windows targeting OSX. More likely, we would be debugging an app that was built on Windows but links with libraries that were built on OSX.
I've thought of various ways to fit this into lldb...
One idea was to add:
settings set target.pathsyntax [posix|windows|any|native] #default=native
and a FileSpec::ePathSyntaxAny enum which would be set if the user chose "any".
But that doesn't solve the problem for llvm, whose path handling appears to be controlled by the define LLVM_ON_WIN32.
Ideas?
Since the lldb-mi tests don't run on Windows, I don't see how that would be possible.
This command uses "target modules lookup" to obtain the information while -symbol-list-lines uses "target modules dump line-table". Although there is difference in the format of the output of these 2 commands, the format for path and line is same. I think we should have one code handling path strings in both of these places to avoid duplication.
It would be even better if we have some API which we can use to query this data. Then there would be no need for this parsing.
Good point. Yes, it would be good to encapsulate this. I'll rework this patch accordingly when I can find the time (busy with a release now).
That said, I would love to continue the discussion of how to tackle the filename/path issue so I can have some direction as to how to resolve it. Should that move to lldb-dev?
This changes the code to use regex to handle the parsing. It is cleaner, more accurate, and faster than the previous code, while not requiring special support to check for Windows paths.
In reworking this patch, I discovered a major bug in -symbol-list-lines where it didn't check the filename so would report lines in header files as belonging to the compilation unit. That is fixed in this patch and a test added, but to fix -symbol-list-lines for header files requires a rewrite of -symbol-list-lines which I didn't have time for. I've added a FIXME for now.
I'm probably not the best person for this since I don't know anything about
the MI stuff
We dont use the lldb_private stuff inside lldb-mi. Please see the discussion in the following thread.
http://lists.llvm.org/pipermail/lldb-dev/2015-March/007047.html
Thank you for your review and for the link. I agree in general and have avoided lldb_private myself, but this means duplicated code which is arguably worse. I think it's time to make lldb-mi a proper part of lldb to avoid reinventing the wheel, or adding SB APIs that make no sense outside of lldb-mi. But I am sympathetic to both arguments so will revise.
The FileSpec is not even used for anything is it? If you want to use the
RegularExpression, then use llvm's regular expression. Honestly LLDB's
regular expression should be deprecated anyway, there's no reason to have
an LLDB regex and an LLVM regex when just one will suffice
No, that was a carry over from a previous patch - now deleted.
If you want to use the
RegularExpression, then use llvm's regular expression. Honestly LLDB's
regular expression should be deprecated anyway, there's no reason to have
an LLDB regex and an LLVM regex when just one will suffice
I agree.
But for now, I've written a small regex wrapper for lldb-mi based on llvm's C regex implementation which uses lldb-mi's string types. It would be awesome to replace lldb-mi's types with those of llvm someday (e.g. have CMIUtilString use StringRef instead of std::string, etc), so that it would be easier to use llvm's classes.
You forgot to add the MIUtilParse.cpp to CMakeLists.txt. Please add it and then it is good to go. Thanks for doing it.
test/tools/lldb-mi/symbol/main.cpp | ||
---|---|---|
12 ↗ | (On Diff #34812) | Don't impose restrictions on the main file which contains test cases for symbol-xxx commands. If a new cases should be added, we will be forced to modify this test case (or be sure that we are still between 20-29 lines). I don't want to care about existing test cases when adding a new one. So please keep this file independent of line numbers, and move all your line-dependent code to a new file. For me, it should look like: int main () { [...] symbol_list_lines_for_inline_test(); [...] } symbol_list_lines_for_inline_test.cpp: // Skip lines so we can make sure we're not seeing any lines from x.h [...] // line 17 // line 18 // line 19 #include "x.h" extern int j; extern int gfunc(int i); int i; void symbol_list_lines_for_inline_test() { i = gfunc(j); i += ns::s.mfunc(); i += ns::ifunc(i); } And rename x.[h,cpp] to something more informative (symbol_list_lines_for_inline_test_x.[cpp|h] would be better). |
test/tools/lldb-mi/symbol/x.h | ||
1–14 ↗ | (On Diff #34812) | Please fix the indentation here (for ex, use clang-format) |
tools/lldb-mi/MIUtilString.cpp | ||
69 ↗ | (On Diff #34812) | Remove this empty line |
Ilia, You did the initial implementation of -symbol-list-lines right? I've fixed a major bug in your code with this commit! You have -symbol-list-lines including lines from header files in the compilation unit! Give the test in this patch a try and you will see. It means you get bogus line information.
Oops! I'm sorry, I think I've misunderstood your issue. You are talking about the test case itself, not the restriction on the filename in the -symbol-list-lines code right? OK, no problem.
Could you please take a look at these issues?
TestMiSymbol started to fail on Linux with gcc-4.9:
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/6387
lldb/trunk/tools/lldb-mi/MIUtilParse.h | ||
---|---|---|
13 | This caused a build failure on OS X: |
Hi Chaoren,
I believe the issue with gcc was fixed for gcc a while back. Just checking to make sure you're no longer seeing the failure. Let me know otherwise.
lldb/trunk/tools/lldb-mi/MIUtilParse.h | ||
---|---|---|
13 | This was fixed by Sean - the XCode build wasn't including the full set of include paths when building lldb-mi. |
Yeah, it seems like it's been passing for gcc-4.9 for a while now. Thanks
for checking!
This caused a build failure on OS X:
http://lab.llvm.org:8011/builders/lldb-x86_64-darwin-13.4/builds/5801