This is an archive of the discontinued LLVM Phabricator instance.

[LLD][COFF] Fix TypeServerSource matcher with more than one collision
ClosedPublic

Authored by thieta on Apr 5 2022, 11:22 PM.

Details

Summary

Follow-up from 98bc304e9faded44f1d8988ffa4c5d8b50c759ec - while that
commit fixed when you had two PDBs colliding on the same Guid it didn't
fix the case where you had more than two PDBs using the same Guid.

This commit fixes that and also tests much more carefully that all
the types are correct no matter the order.

Diff Detail

Event Timeline

thieta created this revision.Apr 5 2022, 11:22 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 5 2022, 11:22 PM
thieta requested review of this revision.Apr 5 2022, 11:22 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 5 2022, 11:22 PM
aganea accepted this revision.Apr 6 2022, 6:18 AM

This looks good, but please see my other comment first! https://reviews.llvm.org/D122372#3432711

This revision is now accepted and ready to land.Apr 6 2022, 6:18 AM
thieta updated this revision to Diff 420870.Apr 6 2022, 8:10 AM

Fixed an issue and added more careful testing.

thieta added a comment.Apr 6 2022, 8:12 AM

@aganea Added more testing - adding a third collision and also probe all the types and in different orders, since the order fooled the testing the first time since the order they where processed in LLD made a difference for the output.

I had to drop the log message since when we know set the entry to nullptr there is nothing informative to log, but I am not convinced the log message was that useful and I really don't think it's worth adding some more complexity to store the paths of all collisions.

WDYT?

thieta retitled this revision from [LLD][COFF] Follow-up on 98bc304 - make collision case faster to [LLD][COFF] Fix TypeServerSource matcher with more than one collision.Apr 6 2022, 8:15 AM
thieta edited the summary of this revision. (Show Details)
aganea added a comment.Apr 6 2022, 8:21 AM

@aganea Added more testing - adding a third collision and also probe all the types and in different orders, since the order fooled the testing the first time since the order they where processed in LLD made a difference for the output.

I had to drop the log message since when we know set the entry to nullptr there is nothing informative to log, but I am not convinced the log message was that useful and I really don't think it's worth adding some more complexity to store the paths of all collisions.

WDYT?

I agree, you can leave out the logging.

lld/test/COFF/pdb-type-server-guid-collision-invalid.test
9 ↗(On Diff #420870)

Are you able to repro the issue with this test, but with the old code from rG98bc304e9faded44f1d8988ffa4c5d8b50c759ec? If so, all good!

thieta added inline comments.Apr 6 2022, 8:22 AM
lld/test/COFF/pdb-type-server-guid-collision-invalid.test
9 ↗(On Diff #420870)

Yes - I wrote the test for the old rev and made sure it failed first.

aganea accepted this revision.Apr 6 2022, 8:23 AM

LGTM.

lld/test/COFF/pdb-type-server-guid-collision-invalid.test
9 ↗(On Diff #420870)

Cool - thanks! ;-)

thieta added inline comments.Apr 6 2022, 8:24 AM
lld/test/COFF/pdb-type-server-guid-collision-invalid.test
9 ↗(On Diff #420870)

Thank you! I totally missed this case the last time around - so it was a great catch.

saudi accepted this revision.Apr 6 2022, 8:56 AM

LGTM
I was curious whether it would be good to remove the notion of GUID validity from the tests, since we now have support for collision whatever the GUIDs are.
I just noticed it, but it was already the case in D122372, so it might be for a separate patch if we want that.

Yeah I think the tests can be improved a bit - but I'll submit a separate patch for that when I have time to dig in. For now I will merge this so it ends up in 14.0.1.