Page MenuHomePhabricator

[NativePDB] Read inc-link thunks from /* LINKER */ module and create symbols
Needs ReviewPublic

Authored by lanza on Jun 18 2019, 4:21 PM.

Details

Summary

The "/* LINKER */" module contains symbols for thunks used for incremental
linking. A callq to a symbol gets statically linked to a thunk that is just a
jmp to the actual target symbol. This information is contained in this "/*
LINKER */" module.

In order for ThreadPlans to handle stepping through these thunks there has to be
something pertaining to it returned from ResolveSymbolContext. So while looking
up symbols in the PDB by VA we can create a Symbol from the PDB Symbol type
which was previously ignored and then the ThreadPlan can properly handle this
step.

Event Timeline

lanza created this revision.Jun 18 2019, 4:21 PM
lanza retitled this revision from [PDB] Read inc-link thunks from /* LINKER */ module and create symbols to [NativePDB] Read inc-link thunks from /* LINKER */ module and create symbols.Jun 18 2019, 5:53 PM
lanza updated this revision to Diff 205499.Jun 18 2019, 7:22 PM

Fix a test

source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
982–1006

I think that this stuff should be in AddSymbols function. After changing a symtab we should call CalculateSymbolSizes and Finalize on it (you can take a look on the implementation in the old PDB plugin).

992

May be it would be better to pass nullptr here to avoid possible name conflicts with e.g. functions with the same name?

1147

I'm pretty sure that using std::unique_ptr after releasing it is not a good idea. There will be a null pointer dereference here.

source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
209–218

Why is this necessary? The change looks unrelated to the old PDB plugin. I think that it would be better to make SymbolFilePDBTests work over the native PDB plugin instead.