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

Thu Jun 7 02:53:16 PDT 2018

aleksandr.urakov added a comment.

Yes, it does really need to be a VS PDB. Function-level linking is a linker's feature and I can't found support of this feature in lld, so I think module addresses inconsistency will not be reproducible with lld.

I've tried to convert a VS PDB to YAML and back in the next way:

> llvm-pdbutil.exe pdb2yaml -all test-pdb-function-level-linking.pdb > test-pdb-function-level-linking.yaml
>  llvm-pdbutil.exe yaml2pdb test-pdb-function-level-linking.yaml

and I have put it near the executable, but it seems that the PDB was broken - nor lldb, nor IDA can load it, but I didn't investigated the problem in detail yet.

As for executable binaries, I think the key problem is that SymbolFilePDBTests has two responsibilities:

- Test the retrieving of data from PDB. All tests find a PDB location from the executable binary (e.g. TestAbilitiesForPDB checks that we have found a correct symbol file) and then somehow retrieve data from the PDB (e.g. via DIA interface). As far as I understand, this part is not tested somewhere else. This part requires original executable and PDB binaries.

- Test the processing of retrieved data (e.g. building the line table), and this is exactly our case. Now this part requires binaries only in VerifyLineEntry function. It uses a module object to convert a virtual address to an Address structure. The structure is used by the line table to a find corresponding entry, but I think that we can introduce a new function for this purpose, which would work with simple file address. So we can avoid using of the module object in VerifyLineEntry function, and make this part independent of binaries.

So if we will split testing of this parts and will find a way to load symbol information from some intermediate form, I think it will be possible to reduce binaries usage. But it requires some more time and investigation.

https://reviews.llvm.org/D47708