[Lldb-commits] [PATCH] D59370: Return llvm::Error and llvm::Expected from some DWARF parsing functions

[Zachary Turner via Phabricator via lldb-commits]

zturner created this revision.
zturner added reviewers: labath, clayborg, aprantl, probinson.
Herald added a subscriber: jdoerfert.

The goal here is to improve our error handling and error recovery while parsing DWARF, while at the same time getting us closer to being able to merge LLDB's DWARF parser with LLVM's.  To this end, I've udpated several of the low-level parsing functions in LLDB to return `llvm::Error` and `llvm::Expected`.

For now, this only updates LLDB parsing functions and not LLVM.  In some ways, this actually gets us *farther* from parity with the two interfaces, because prior to this patch, at least the parsing interfaces were the same (i.e. they all just returned bools, and now with this patch they're diverging).  But, I chose to do this for two primary reasons.

1. LLDB has error logging code engrained deep within some of its parsing functions.  We don't want to lose this logging information, but obviously LLVM has no logging mechanism at all.  So if we're to merge the interfaces, we have to find a way to still allow LLDB to properly report parsing errors while not having the reporting code be inside of LLVM.

2. LLDB (and indeed, LLVM) overload the meaning of the `false` return value from all of these extraction functions to mean both "We reached the null entry at the end of a list of items, therefore everything was successful" as well as "something bad and unrecoverable happened during parsing".  So you would have a lot code that would do something like:

  while (foo.extract(...)) {
    ...
  }

But when the loop stops, why did it stop?  Did it stop because it finished parsing, or because there was an error?  Because of this, in some cases we don't always know whether it is ok to proceed, or how to proceed, but we were doing it anyway.

In this patch, I solve the second problem by introducing an enumeration called `DWARFEnumState` which has two values `MoreItems and `Complete`.  Both of these indicate success, but the latter indicates that we reached the null entry.  Then, I return this value instead of bool, and convey parsing failure separately.

To solve the first problem (and convey parsing failure) these functions now return either `llvm::Error` or `llvm::Expected<DWARFEnumState>`.  Having this extra bit of information allows us to properly convey all 3 of us "error, bail out", "success, call this function again", and "success, don't call this function again".

In subsequent patches I plan to extend this pattern to the rest of the parsing interfaces, which will ultimately get all of the log statements and error reporting out of the low level parsing code and into the high level parsing code (e.g. `SymbolFileDWARF`, `DWARFASTParserClang`, etc).

Eventually, these same changes will have to be backported to LLVM's DWARF parser, but I feel like diverging in the short term is the quickest way to converge in the long term.


https://reviews.llvm.org/D59370

Files:
  lldb/source/Plugins/SymbolFile/DWARF/DWARFAbbreviationDeclaration.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFAbbreviationDeclaration.h
  lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugAbbrev.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugAbbrev.h
  lldb/source/Plugins/SymbolFile/DWARF/DWARFDefines.h
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D59370.190647.patch
Type: text/x-patch
Size: 9752 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20190314/37b71af4/attachment.bin>