-
Notifications
You must be signed in to change notification settings - Fork 15.2k
[LLVM] Create lf_alias
nodes for typedef
and using
#153936
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1728,14 +1728,17 @@ TypeIndex CodeViewDebug::lowerTypeAlias(const DIDerivedType *Ty) { | |
|
||
addToUDTs(Ty); | ||
|
||
AliasRecord AR(UnderlyingTypeIndex, TypeName); | ||
auto alias_index = TypeTable.writeLeafType(AR); | ||
|
||
|
||
if (UnderlyingTypeIndex == TypeIndex(SimpleTypeKind::Int32Long) && | ||
TypeName == "HRESULT") | ||
return TypeIndex(SimpleTypeKind::HResult); | ||
if (UnderlyingTypeIndex == TypeIndex(SimpleTypeKind::UInt16Short) && | ||
TypeName == "wchar_t") | ||
return TypeIndex(SimpleTypeKind::WideCharacter); | ||
|
||
return UnderlyingTypeIndex; | ||
return alias_index; | ||
} | ||
|
||
TypeIndex CodeViewDebug::lowerTypeArray(const DICompositeType *Ty) { | ||
|
@@ -2750,14 +2753,6 @@ TypeIndex CodeViewDebug::getCompleteTypeIndex(const DIType *Ty) { | |
if (!Ty) | ||
return TypeIndex::Void(); | ||
|
||
// Look through typedefs when getting the complete type index. Call | ||
// getTypeIndex on the typdef to ensure that any UDTs are accumulated and are | ||
// emitted only once. | ||
if (Ty->getTag() == dwarf::DW_TAG_typedef) | ||
(void)getTypeIndex(Ty); | ||
while (Ty->getTag() == dwarf::DW_TAG_typedef) | ||
Ty = cast<DIDerivedType>(Ty)->getBaseType(); | ||
|
||
// If this is a non-record type, the complete type index is the same as the | ||
// normal type index. Just call getTypeIndex. | ||
switch (Ty->getTag()) { | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -614,6 +614,11 @@ template <> void LeafRecordImpl<EndPrecompRecord>::map(IO &IO) { | |
IO.mapRequired("Signature", Record.Signature); | ||
} | ||
|
||
template <> void LeafRecordImpl<AliasRecord>::map(IO &IO) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we test this? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I believe so, I would dig around in the yaml tests for an example to add to. |
||
IO.mapRequired("UnderlyingType", Record.UnderlyingType); | ||
IO.mapRequired("Name", Record.Name); | ||
} | ||
|
||
template <> void MemberRecordImpl<OneMethodRecord>::map(IO &IO) { | ||
MappingTraits<OneMethodRecord>::mapping(IO, Record); | ||
} | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,14 @@ | ||
// Build with clang -fno-rtti -g -O0 typedef.cpp | ||
// Built with clang (22+) because MSVC does not output lf_alias for typedefs | ||
|
||
void *__purecall = 0; | ||
|
||
|
||
typedef unsigned char u8; | ||
using i64 = long long; | ||
|
||
int main() { | ||
u8 val = 15; | ||
i64 val2 = -1; | ||
|
||
return 0; | ||
} |
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As @Michael137 says above, the whole test should be self-enclosed. The test, the inputs and the post-checks should all live in this file. Please look at past commits to understand how other LF_* records were implemented / tested. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not super familiar with LLVM's test structure, but I more or less copied the surrounding tests. All of the native pdb tests use pre-compiled PDB files and they seem to all be testing "can LLVM's native reader read the node", not "can LLVM generate the node". They're compiled with Do the tests for LLVM's node generation live somewhere else, and would that test be more appropriately placed there? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yea that's fair. Though off the top I don't see a good reason why it was done this way for the other tests. Perhaps the test infrastructure wasn't mature enough? @rnk will probably know I'm not a PDB/CodeView expert, so I might be misunderstanding what's required to test these changes. But does Clang generate PDBs when you specify There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @Walnut356 We usually cover "can LLVM read the node" and "can LLVM generate the node" at once. There are some rare cases, such as An example of this: https://github.com/llvm/llvm-project/blob/main/llvm/test/DebugInfo/PDB/obj-globalhash.test Another example which uses There might be some legacy binaries lying around but ideally if LLVM can generate the As for location, the tests should go in https://github.com/llvm/llvm-project/tree/main/llvm/test/DebugInfo There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. +1, right, we mostly need(ed) the binaries to bootstrap file parsing. Now that the tools can read and write these records, the cost of additional binary test inputs outweighs the increase in confidence we get from validating that our tools can read one additional codeview record from MSVC outputs. Another way of looking at this is that we committed binary files as test inputs in a pre-xz-attack world, and now binary files are one of the biggest negatives on the LLVM project OpenSSF security scorecard: So, things have actually changed, standards have increased, and what worked yesterday won't fly today. 😦 I want to unblock and enable contributions, but I don't want to make the problem worse at this point. I'm sure this feels unfair, but I hope that context helps explain the shift. In an ideal world, we'd do the work to delete the binary inputs by YAML-ifying the parts of the tests that we need to and replacing the rest using other strategies. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,8 @@ | ||
RUN: llvm-pdbutil dump -type-index=0x348A,0x348C %p/Inputs/typedef.pdb \ | ||
RUN: | FileCheck --check-prefix=TYPES %s | ||
|
||
TYPES: Types (TPI Stream) | ||
TYPES-NEXT:============================================================ | ||
TYPES-NEXT: Showing 2 records. | ||
TYPES-NEXT: 0x348A | LF_ALIAS [size = 12] alias = u8, underlying type = 0x0020 (unsigned char) | ||
TYPES-NEXT: 0x348C | LF_ALIAS [size = 12] alias = i64, underlying type = 0x0013 (__int64) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove extra blank line