This is an archive of the discontinued LLVM Phabricator instance.

[llmv-pdbutil] Replace ExitOnError with explicit error handling.
ClosedPublic

Authored by CarlosAlbertoEnciso on Mar 16 2022, 6:48 AM.

Details

Summary

[llmv-pdbutil] Replace ExitOnError with explicit error handling.

At Sony we are developing llvm-dva

https://lists.llvm.org/pipermail/llvm-dev/2020-August/144174.html

For its PDB support, it requires functionality already present
in llvm-pdbutil.

We intend to move that functionaly into the PDB library to be
shared by both tools. That change will be done in 2 steps, that
will be submitted as 2 patches:

(1) Replace 'ExitOnError' with explicit error handling.
(2) Move the intended shared code to the PDB library.

This patch is for step (1).

As 'ExitOnError' is intended to be used only in tool code, replace
all occurrences in the code that will be moved to the PDB library
with explicit error handling.

Diff Detail

Event Timeline

Herald added a project: Restricted Project. · View Herald TranscriptMar 16 2022, 6:48 AM
CarlosAlbertoEnciso requested review of this revision.Mar 16 2022, 6:48 AM
aganea added inline comments.Mar 16 2022, 8:32 AM
llvm/tools/llvm-pdbutil/DumpOutputStyle.cpp
455

The user would loose the context after removal of this line, if the message is printed on stderr. Can you move this line to L201, or replace it by an extra StringError if you plan on moving this entire file to the PDB library? It could be something like:

if (opts::dump::DumpSymbols) {
  auto EC = File.isPdb() ? dumpModuleSymsForPdb() : dumpModuleSymsForObj();
  if (EC)
    return joinErrors(createStringError(inconvertibleErrorCode(), "Unexpected error processing modules:"), EC);
}
681

You can early exit here.

llvm/tools/llvm-pdbutil/InputFile.cpp
40–43

Even though auto is already used throughout this file, I find it's hard for a person reading the code to understand what type the function returns. Also please see https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable

It's probably better if we wrote Expected<DbiStream &> DbiOrErr = ... and DbiStream &Dbi = ... below. Same applies for other places/usage of auto throughout this patch.

rnk added a comment.Mar 16 2022, 10:56 AM

Essentially, this looks good to me. I have some minor concerns that as we migrate dumping functionality into library code, it will tend to increase the code size of production tools such as the linker. Maybe archive semantics and section GC paper over those problems. However, in the end I don't think it makes sense to worry about unmeasured, hypothetical code size problems. If there are problems, I guess it would make sense to factor out "dumping" functionanlity from the PDB and CodeView libraries into their own CVDump helper library or something. This is similar to how we pulled YAML writing out of lib/Object.

llvm/tools/llvm-pdbutil/InputFile.cpp
40–43

I wanted to ask if we can write Expected<auto>, but no, that is not valid C++. :(

I don't think I can make a strong argument for either direction. Fully writing out all Expected types seems onerous, but this also seems like an overuse of auto. The type that the reader cares about most is probably DbiStream.

dblaikie added inline comments.
llvm/tools/llvm-pdbutil/InputFile.cpp
40–43

I'm mostly OK with using auto for Expected - especially if you're going to name the extracted value, as is done here (Dbi) - if you want to include the type name for that for readability, you could include it there (DbiStream &Dbi = *DbiOrErr). To me - the Expected's pratical use/scope is 4 lines, and the variable name and its 3 uses all communicate, to me at least, pretty clearly what it is/how it's being used.

40–43

But I should say I don't feel super strongly either way - as @rnk said.

aganea added inline comments.Mar 16 2022, 11:03 AM
llvm/tools/llvm-pdbutil/InputFile.cpp
40–43

Agreed - the most important is to have DbiStream &Dbi = *DbiOrErr; below.

CarlosAlbertoEnciso added a comment.EditedMar 17 2022, 5:10 AM

As stated, we intend to move some functionality into the PDB library:

Patch (1) Replace 'ExitOnError' with explicit error handling.
Patch (2) Move the intended shared code to the PDB library.

With the moved functionality, we are able to:

  • Open a PDB file.
  • Get module debug stream.
  • Traverse module sections.
  • Traverse module subsections.

The second patch only moves InputFile.cpp[h], LinePrinter.cpp[h] and FormatUtil.cpp[h] files.

Most of the needed functionality is in InputFile, but there are dependencies from LinePrinter and FormatUtil.

Some other functionality is in the following functions in DumpOutputStyle.cpp file:

  • iterateModuleSubsections
  • getModuleDebugStream
  • iterateOneModule
  • iterateSymbolGroups
  • iterateModuleSubsections

Only these specific functions from DumpOutputStyle are moved to the PDB library.

  • Added details about the intended second patch, that includes: files and functions being moved into the PDB library.
  • Replaced the 'auto' for the specific: Expected<DbiStream &> and DbiStream.
  • Added an early exit.

The only remainding comment not addressed is from @aganea, in relation to the

ExitOnError Err("Unexpected error processing modules: ");
llvm/tools/llvm-pdbutil/DumpOutputStyle.cpp
455

Very valid point.

The following functions are affected:

Error DumpOutputStyle::dumpModules();
Error DumpOutputStyle::dumpModuleFiles();
Error DumpOutputStyle::dumpSymbolStats();
Error DumpOutputStyle::dumpModuleSymsForPdb();

What I am suggesting is to pass an additional parameter to the functions that are intended to be moved to the PDB library that now are returning an Error and add your suggested code to those functions.

if (EC)
    return joinErrors(createStringError(inconvertibleErrorCode(), ExtraMessage), EC);
681

Added the early exit.

CarlosAlbertoEnciso marked 5 inline comments as done.Mar 17 2022, 7:17 AM
aganea accepted this revision.Mar 17 2022, 7:47 AM

LGTM, thanks!

Essentially, this looks good to me. I have some minor concerns that as we migrate dumping functionality into library code, it will tend to increase the code size of production tools such as the linker. Maybe archive semantics and section GC paper over those problems. However, in the end I don't think it makes sense to worry about unmeasured, hypothetical code size problems. If there are problems, I guess it would make sense to factor out "dumping" functionanlity from the PDB and CodeView libraries into their own CVDump helper library or something. This is similar to how we pulled YAML writing out of lib/Object.

@CarlosAlbertoEnciso Would you be able to provide some numbers please along with patch (2)? At least we'll be settled if this code move should go in a new lib or not.

llvm/tools/llvm-pdbutil/DumpOutputStyle.cpp
455

I guess you can also move the ExitOnError closer to the caller site:

Error DumpOutputStyle::dump() {
  ...
  if (opts::dump::DumpModules) {
    ExitOnError Err("Unexpected error processing modules: ");
    Err(dumpModules());
  }
This revision is now accepted and ready to land.Mar 17 2022, 7:47 AM
llvm/tools/llvm-pdbutil/DumpOutputStyle.cpp
455

Added your suggested change to the caller sites that are missing the ExitOnError.

Addressed the remainding comment from @aganea, in relation to the

ExitOnError Err("Unexpected error processing modules: ");

This revision was landed with ongoing or failed builds.Mar 20 2022, 10:28 PM
This revision was automatically updated to reflect the committed changes.