This is an archive of the discontinued LLVM Phabricator instance.

[PDB] Support following Type server records
ClosedPublic

Authored by zturner on Feb 14 2017, 4:25 PM.

Details

Summary
[pdb] Add the ability to resolve TypeServer PDBs.

Some PDBs or object files can contain references to other PDBs
where the real type information lives.  When this happens,
all type indices in the original PDB are meaningless because
their records are not there.

With this patch we add the ability to pull type info from those
secondary PDBs, and update LLD to do so when it merges.

Diff Detail

Repository
rL LLVM

Event Timeline

zturner created this revision.Feb 14 2017, 4:25 PM
ruiu added inline comments.Feb 15 2017, 2:26 PM
llvm/include/llvm/DebugInfo/CodeView/TypeServerHandler.h
20 ↗(On Diff #88466)

I think you want to define a virtual dtor to silence -Wnon-virtual-dtor.

llvm/lib/DebugInfo/PDB/Native/PDBTypeServerHandler.cpp
7 ↗(On Diff #88466)

Can you write a file comment what we are doing in this file? E.g. a LF_TYPESERVER2 record referes an external pdb file, so we read that file and replace TypeServer2Record with the file contents.

33 ↗(On Diff #88466)

Calling this function more than once with the same argument seems to add the same element to to SearchPaths. Is this a desired behavior?

40 ↗(On Diff #88466)

You want to change this to Error and return Error::success() on success.

80 ↗(On Diff #88466)

I believe that evaluating EC as a boolean value clears "checked" bits of the object, so you can safely ignore errors without calling this.

92 ↗(On Diff #88466)

Please add a comment -- GUID must be the same.

zturner added inline comments.Feb 15 2017, 3:11 PM
llvm/lib/DebugInfo/PDB/Native/PDBTypeServerHandler.cpp
40 ↗(On Diff #88466)

Error is not quite the same. Here I want to return 3 possible pieces of information:

  1. Caller should assume the type server record has been handled.
  2. Caller should assume the type server record has not been handled.
  3. An error occurred. (For example the file was corrupt).

1 and 2 are distinct non-error conditions though. In case 1, the caller stops processing this record and goes to the next one in the stream. In case 2, caller keeps searching through the list of handlers in case another one can handle it. But in case 3, something bad happened and the caller probably has to exit and report an error.

zturner added inline comments.Feb 15 2017, 3:36 PM
llvm/lib/DebugInfo/PDB/Native/PDBTypeServerHandler.cpp
33 ↗(On Diff #88466)

I don't feel strongly either way, if you think it's better to change it I can.

80 ↗(On Diff #88466)

Error only clears checked bit if it was in a success state. You have to check it regardless of if it's success or failure, but if it's an error condition you also have to handle it.

/// Bool conversion. Returns true if this Error is in a failure state,
/// and false if it is in an accept state. If the error is in a Success state
/// it will be considered checked.
explicit operator bool() {
  setChecked(getPtr() == nullptr);
  return getPtr() != nullptr;
}
zturner updated this revision to Diff 88618.Feb 15 2017, 3:36 PM
ruiu accepted this revision.Feb 16 2017, 12:36 PM

LGTM

llvm/lib/DebugInfo/PDB/Native/PDBTypeServerHandler.cpp
33 ↗(On Diff #88466)

I don't have a preference, so this is fine.

16 ↗(On Diff #88618)

no corresponding '('?

This revision is now accepted and ready to land.Feb 16 2017, 12:36 PM
This revision was automatically updated to reflect the committed changes.