Do you have an easy way to check what DIA version that is?  Anyway, thanks for fixing it!<br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 6, 2018 at 1:53 AM Hans Wennborg <<a href="mailto:hans@chromium.org">hans@chromium.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Jul 6, 2018 at 4:33 AM, Zachary Turner via llvm-commits<br>
<<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<br>
> Author: zturner<br>
> Date: Thu Jul  5 19:33:58 2018<br>
> New Revision: 336405<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=336405&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project?rev=336405&view=rev</a><br>
> Log:<br>
> [PDB] Sort globals symbols by name in GSI hash buckets.<br>
><br>
> It seems like the debugger first computes a symbol's bucket,<br>
> and then does a binary search of entries in the bucket using the<br>
> symbol's name in order to find it.  If the bucket entries are not<br>
> in sorted order, this obviously won't work.  After this patch a<br>
> couple of simple test cases show that we generate an exactly<br>
> identical GSI hash stream, which is very nice.<br>
[..]<br>
> Added: lld/trunk/test/COFF/pdb-globals-dia-vfunc-collision.test<br>
> URL: <a href="http://llvm.org/viewvc/llvm-project/lld/trunk/test/COFF/pdb-globals-dia-vfunc-collision.test?rev=336405&view=auto" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project/lld/trunk/test/COFF/pdb-globals-dia-vfunc-collision.test?rev=336405&view=auto</a><br>
> ==============================================================================<br>
> --- lld/trunk/test/COFF/pdb-globals-dia-vfunc-collision.test (added)<br>
> +++ lld/trunk/test/COFF/pdb-globals-dia-vfunc-collision.test Thu Jul  5 19:33:58 2018<br>
> @@ -0,0 +1,42 @@<br>
> +REQUIRES: diasdk<br>
> +<br>
> +Input object file reconstruction:<br>
> +<br>
> +; // main.cpp<br>
> +; struct S {<br>
> +;   // Function names are chosen specifically to generate hash collisions in the<br>
> +;   // GSI hash table.<br>
> +;   virtual int A307() { return 102; }<br>
> +;   virtual int A400() { return 12; }<br>
> +;   virtual int A206() { return 201; }<br>
> +;   virtual int A105() { return 300; }<br>
> +; };<br>
> +;<br>
> +; struct T : public S {<br>
> +;   int A105() override { return 300; }<br>
> +;   int A307() override { return 102; }<br>
> +;   int A206() override { return 201; }<br>
> +;   int A400() override { return 12; }<br>
> +; };<br>
> +;<br>
> +; int main(int argc, char **argv) {<br>
> +;   T s;<br>
> +;   return s.A105() + s.A206() + s.A307() + s.A400();<br>
> +; }<br>
> +<br>
> +clang-cl /Z7 /GS- /GR- /c main.cpp /Foglobals-dia-vfunc-collision.obj<br>
> +<br>
> +RUN: lld-link /debug /nodefaultlib /entry:main /out:%t.exe %S/Inputs/globals-dia-vfunc-collision.obj<br>
> +RUN: llvm-pdbutil pretty -classes %t.pdb | FileCheck %s<br>
> +<br>
> +CHECK: struct T<br>
> +CHECK: func [0x000010c0+ 0 - 0x000010dd-29 | sizeof= 29] (FPO) virtual int __cdecl A105()<br>
<br>
In Chromium's build this failed [1] because DIA was printing the qualified name:<br>
<br>
<stdin>:10:2: note: possible intended match here<br>
 func [0x000010c0+ 0 - 0x000010dd-29 | sizeof= 29] (FPO) virtual int<br>
__cdecl T::A105()<br>
 ^<br>
<br>
Maybe because the bot uses a different DIA version. I've relaxed the<br>
check a little in r336424.<br>
<br>
 [1] <a href="https://logs.chromium.org/v/?s=chromium%2Fbb%2Ftryserver.chromium.win%2Fwin_upload_clang%2F365%2F%2B%2Frecipes%2Fsteps%2Fpackage_clang%2F0%2Fstdout" rel="noreferrer" target="_blank">https://logs.chromium.org/v/?s=chromium%2Fbb%2Ftryserver.chromium.win%2Fwin_upload_clang%2F365%2F%2B%2Frecipes%2Fsteps%2Fpackage_clang%2F0%2Fstdout</a><br>
</blockquote></div>