This patch adds DWARF embedded source printout to llvm-symbolizer.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/DebugInfo/Symbolize/DIPrinter.cpp | ||
---|---|---|
121–122 | Could you pull this (& any other refactoring you think makes the semantic-changing patch more isolated/focussed) into a preliminary commit? | |
305–322 | I take it this is trimming the trailing lines that won't be needed, while leaving the leading lines so the algorithm in printContext can still retrieve the lines in a source-agnostic way (so it can retrieve them in the same way from embedded source as non-embedded source) It seems unfortunate to have split the pruning logic in two places like this - perhaps a generic function that takes the line iterator & just the desired context (pruning both leading and trailing lines) - then use that function here, and have the "Source" attribute contain the fully pruned text. Then in printContext if the Source value is provided, use that literally - otherwise open the file and prune its leading/trailing using the same function? (also that refactoring - pulling out such a reusable pruning function - should be done as a separate commit) |
llvm/lib/DebugInfo/Symbolize/DIPrinter.cpp | ||
---|---|---|
309 | Note llvm::line_iterator is badly designed. | |
316–325 | Correct. I copied the Source context to JSON as is in the first implementation. Then I decided to format it too. I have moved the code to the common function format(). |
llvm/lib/DebugInfo/Symbolize/DIPrinter.cpp | ||
---|---|---|
309 | Note the current implementation of line_iterator can be used with the full source, but not with the pruned source if it didn't coincide with the end of the source file. |
llvm/lib/DebugInfo/Symbolize/DIPrinter.cpp | ||
---|---|---|
92 | This still isn't valid - there's no guarantee that end is dereferenceable. (using [] doesn't make the code any safer/different - it's still a dereference) | |
309 | Either the code will need to unconditionally copy the StringRef into a std::string (in which case, maybe it'd be simpler if the SourceCode structure stored the data in a std::string in the first place? then it wouldn't need the MemoryBuffer member either, since it wouldn't be holding live pointers to the memory mapped file) - or the line_iterator would need to be fixed or a different tool used - which, maybe that's the thing to do? If the original code that extracted the relevant lines already used the line iterator (so features like blank line skipping, etc, have already been handled) - maybe this code could do something simpler, like splitting on newlines, rather than using the full line iterator? |
llvm/lib/DebugInfo/Symbolize/DIPrinter.cpp | ||
---|---|---|
92 | I just used the same checking as llvm/lib/Support/LineIterator.cpp, line 47: assert(Buffer.getBufferEnd()[0] == '\0'); Any suggestions? | |
309 | Note currently line_iterator does not skip blank lines. |
I've got no specific comments on the source code, just one small nit in the test. I'll leave @dblaikie to continue the rest of the review.
llvm/test/tools/llvm-symbolizer/source.ll | ||
---|---|---|
9 | It would probably be a good idea to run the exact same check for GNU output (or llvm-addr2line), just to cover our bases. That way, if the behaviour ever diverges in the future, there's a clear test to update. |
llvm/test/tools/llvm-symbolizer/source.ll | ||
---|---|---|
2 | I think "output" is a more common term to use and easier to understand. | |
8 | No need to repeat "source context" in this text - it's implied by the top-level comment. | |
9 | This is simpler and more traditional for the input arguments. Also CODE is the default and not needed. | |
17 | ||
18 | ||
20–24 | There's only one small difference between this and the LLVM style, if I'm not mistaken. You could avoid duplciation by doing something like: ; RUN: ... | FileCheck ... --check-prefixes=COMMON,LLVM; ; RUN: ... | FileCheck ... --check-prefixes=COMMON,GNU ; COMMON:foo ; LLVM-NEXT:/source.c:3:13 ; GNU-NEXT:/source.c:3 ; COMMON-NEXT:2 : // Line 2 ; COMMON-NEXT:3 >: void foo() {} ; COMMON-NEXT:4 : // Line 4 | |
26 | ||
27 |
This still isn't valid - there's no guarantee that end is dereferenceable. (using [] doesn't make the code any safer/different - it's still a dereference)