[Lldb-commits] [PATCH] D47708: PDB support of function-level linking and splitted functions

Pavel Labath via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Thu Jun 7 02:49:13 PDT 2018

labath added a comment.

In https://reviews.llvm.org/D47708#1124429, @zturner wrote:

> Do you just need a pdb, or does it really need to be a vs pdb? lld can
>  generate high quality pdbs now. So it might be possible to use lld to link
>  and produce a pdb when you run the test.
> Pavel’s suggestion is equally viable, you can dump a pdb to yaml and
>  convert it back to a pdb at test time.
> The real problem is the exe. It’s harder to generate exes at test time
>  because we have to ensure that dependent libraries are present on the
>  system.
> If it has to be an msvc generated pdb, can you elaborate on why? Tbh I’m
>  not really against checking in pdbs. Exes I’d like to find a way to avoid
>  checking in wherever possible though. And even then, sometimes I don’t have
>  any better ideas other than compile and link before running the test

I guess that part that makes generating the exe during test tricky is the feedback loop needed for PGO. I don't know enough about the windows ecosystem to tell if there is a different way to generate these kinds of split line tables (on linux I can think of a several).

I suppose the reason you can't do the same yaml2obj trick on the .exe is because yaml2obj does not support serializing exe's yet?

Comment at: unittests/SymbolFile/PDB/Inputs/test-pdb-splitted-function.cpp:8-9
+#include <cmath>
+#include <iostream>
Could we shrink the size of these binaries by not using c and c++ standard library features?

Comment at: unittests/SymbolFile/PDB/Inputs/test-pdb-splitted-function.cpp:11-27
+int main()
+    auto b = false;
+    for (auto i = 1; i <= 1024; i++)
+    {
+        if (b)
+        {
Could you clang-format this patch?

Comment at: unittests/SymbolFile/PDB/SymbolFilePDBTests.cpp:375-398
+  uint32_t count =
+      symfile->ResolveSymbolContext(source_file, 0, true, scope, sc_list);
+  EXPECT_EQ(1u, count);
+  SymbolContext sc;
+  EXPECT_TRUE(sc_list.GetContextAtIndex(0, sc));
I think these kinds of checks would be a nice fit for a `lldb-test symbols --verify` option.


More information about the lldb-commits mailing list