Page MenuHomePhabricator

[SymbolFilePDB] Fix null array access when parsing the type of a function without any arguments, i.e. 'int main()' and add support to test it
ClosedPublic

Authored by asmith on Dec 19 2017, 8:43 PM.

Details

Summary
  • Fix a null array access bug. This happens when creating the lldb type for a function that has no argument.
  • Implement SymbolFilePDB::ParseTypes method. Using lldb-test symbols will show all supported types in the target.
  • Create lldb types for variadic function, PDBSymbolTypePointer, PDBSymbolTypeBuiltin
  • The underlying builtin type for PDBSymbolTypeEnum is always Int, correct it with the very first enumerator's encoding if any. This is more accurate when the underlying type is not signed or another integer type.
  • Fix a bug when the compiler type is not created based on PDB_BuiltinType. For example, basic type long is of same width as int in a 32-bit target, and the compiler type of former one will be represented by the one generated for latter if using the default method. Introduce a static function GetBuiltinTypeForPDBEncodingAndBitSize to correct this issue.
  • Basic type long double and double have the same bit size in MSVC and there is no information in a PDB to distinguish them. The compiler type of the former one is represented by the latter's.
  • There is no line informaton about typedef, enum etc in a PDB and the source and line information for them are not shown.
  • There is no information about scoped enumeration. The compiler type is represented as an unscoped one.

Diff Detail

Repository
rL LLVM

Event Timeline

asmith created this revision.Dec 19 2017, 8:43 PM

This is another example where we could test it easily if lldb-test could dump this. Are you willing to take a stab at this?

davide added a subscriber: davide.Dec 21 2017, 6:56 AM

Indeed, this needs to be tested.

davide requested changes to this revision.Dec 21 2017, 6:56 AM
This revision now requires changes to proceed.Dec 21 2017, 6:56 AM

This fix is part of a larger set of changes to retrieve the type for a function signature and I don't see how to test for this without those changes. With all the other changes, lldb-test fails without this fix and passes with it. So it's implicitly already tested.

asmith updated this revision to Diff 128069.Dec 22 2017, 8:07 PM
asmith retitled this revision from [lldb] Fix crash when parsing the type of a function without any arguments to Fix crash when parsing the type of a function without any arguments.
asmith edited the summary of this revision. (Show Details)

This was originally written as a unit test because at the time we didn't have lldb-test. To be honest I think it's time to remove these checked in binaries and convert everything to FileCheck tests. There's a couple of reasons this is more practical. For starters, the binaries can be really large and having lots of large binaries in the repo is a real drag for developers. Secondly, we've recently had some bug reports where some virus scan software is flagging our executables as malicious due to some heuristics. So while you're just modifying an existing binary / test, if it's not a ton of work I would really prefer standardizing on lldb-test + FileCheck for this sort of thing. Did you explore that at all?

While there's a little higher up front cost because you have to go update the lldb-test tool to support this, after that work is done it will make writing future tests very easy. All you would need is something like this:

REQUIRES: system-windows
RUN: clang-cl /Z7 /c %S/Inputs/foo.cpp /o %T/foo.cpp.obj
RUN: link /DEBUG /PDB:%T/foo.cpp.pdb /Fo:%T/foo.cpp.exe
RUN: lldb-test symbols -types foo.cpp.exe | FileCheck %s

CHECK: int(*FuncPointerTypedef)();
CHECK: int(*VariadicFuncPointerTypedef)(char,...);
asmith added a comment.Jan 2 2018, 9:10 PM

Do you prefer to drop the test changes and corresponding binaries?
For an llvm-lit test, which directory do you recommend for the new file?

asmith updated this revision to Diff 130088.Jan 16 2018, 8:00 PM
asmith retitled this revision from Fix crash when parsing the type of a function without any arguments to Fix crash when parsing the type of a function without any arguments, i.e. 'int main()'.
asmith edited the summary of this revision. (Show Details)

The test is added and this is ready to go. Let me know if there are any other changes. Thanks!

asmith updated this revision to Diff 130089.Jan 16 2018, 8:05 PM
asmith retitled this revision from Fix crash when parsing the type of a function without any arguments, i.e. 'int main()' to [SymbolFilePDB] Fix null array access when parsing the type of a function without any arguments, i.e. 'int main()' and add support to test it.Jan 16 2018, 8:24 PM
asmith edited the summary of this revision. (Show Details)
zturner accepted this revision.Jan 19 2018, 1:48 PM

Sorry for forgetting about this! lgtm

asmith accepted this revision.Jan 19 2018, 1:54 PM

Revision was approved by zturner in the comments

This revision was not accepted when it landed; it landed in state Needs Review.Jan 19 2018, 1:57 PM
This revision was automatically updated to reflect the committed changes.
majnemer added inline comments.
lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
162–163

Copy paste bug?

labath added a subscriber: labath.Jan 22 2018, 3:57 AM

I have reverted this because this breaks the lldb-Unit::SymbolFilePDBTests.TestTypedefs test http://lab.llvm.org:8011/builders/lldb-windows7-android/builds/7715. My guess is that this is because you did not update the checked-in exe to account for the changes in it's source. I'll leave up to you and Zachary to figure out whether you actually want to update the exe or test everything using the lldb-test approach, but in the mean time, we cannot have failing tests in the repository.