This is an archive of the discontinued LLVM Phabricator instance.

Convert PDB error handling into using std::error_code instead of custom error codes
ClosedPublic

Authored by zturner on May 4 2016, 3:35 PM.

Details

Summary

This centralizes the message translation and also provides a more generic interoperability with other libraries that expect to use std error codes.

Diff Detail

Event Timeline

zturner updated this revision to Diff 56212.May 4 2016, 3:35 PM
zturner retitled this revision from to Convert PDB error handling into using std::error_code instead of custom error codes.
zturner updated this object.
zturner added a reviewer: rnk.
zturner added a subscriber: llvm-commits.

If you like, you might want to consider the recently introduced llvm::Error
which has more checking to ensure errors aren't accidentally
ignored/dropped.

How strong of a recommendation is this? I don't know much about the Error class.

I like the idea of llvm::Error if only because it permits for more descriptive messages like so:

llvm::make_error<GenericError>("unexpected relocation in CIE")

without having to make a billion error codes.

zturner updated this revision to Diff 56323.May 5 2016, 12:00 PM
zturner added a reviewer: lhames.

Convert everything to using llvm::Error.

I chose to do this a little bit different way than what is probably normal. There are two distinct codepaths. The DIA codepath and the native PDB parsing codepaths. I wanted to be able to "namespace" the types of errors that each codepath can produce, so that I could make sure I was not returning a DIA error from the raw codepath, and vice versa.

At the same time, I did not want to make 100 different subclasses of ErrorInfo, but I *did* want error messages to be consistent, so that all corrupt file errors have the same error message, etc.

So I chose a hybrid. I have a DIAError, a RawError, and a GenericError. Each one defines its own set of error code constants that you can (optionally) use when making the error. In all cases you also (optionally) pass a context string that gives more detailed information about the site the error occurred at. This way the class (DIAError, RawError, etc) provides the high level error message banner, the code provides a consistent general description of the error, and the context provides the detail.

A nice advantage of this is that when converting to a std error_code, you already have an error category defines which translates it into a useful error message.

In the future, I have some more ideas here that will make this even better. Instead of using an error code, we can define a class for each custom error condition that takes its own set of constructor arguments and has a format() method. This way we could do something like:

make_error<RawError>(corrupt_file(Path), "No MSF Superblock")

and it could format it as

Native PDB File Error: The PDB file 'c:\foo.pdb' is corrupt.  Reason: No MSF Superblock'

and this corrupt_file class would know how to format the parameters intelligently, instead of just slapping the context onto the end of the string as we currently do.

Adding lang on this review since he wrote the Error stuff, and make he can offer some suggestions about if I'm using this correctly.

majnemer added inline comments.May 5 2016, 12:09 PM
include/llvm/DebugInfo/PDB/DIA/DIASupport.h
25–34

why not push_macro and pop_macro around the dia includes?

Because I'm dumb and forgot about them. Thanks for the reminder

zturner updated this revision to Diff 56326.May 5 2016, 12:55 PM

Somehow uploaded the wrong diff last time. This one should be right.

rnk accepted this revision.May 6 2016, 12:40 PM
rnk edited edge metadata.

lgtm

It would be nice if we could test the error paths here better, but I'd rather not check in distinct corrupt PDBs for every error path. If we ever care about perfect error handling we will need to fuzz this.

lib/DebugInfo/PDB/Raw/DbiStream.cpp
110

Maybe write a helper like errorCorruptFile(StringRef) that you can call here in the return? It might save a line break on all these error paths. Up to you.

This revision is now accepted and ready to land.May 6 2016, 12:40 PM

The test was fixed too, it should be picked up in r268798.

Eugene.Zelenko added a subscriber: Eugene.Zelenko.

Committed in r268791.