Page MenuHomePhabricator

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

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



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

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


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).


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


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.


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.

lanza abandoned this revision.Jan 8 2020, 12:55 PM
lanza marked 5 inline comments as done.
lanza added inline comments.

Is nullptr valid? It attempts to use the string to print numerous labels and just yields a weirdly empty print out. I could possibly just call ResolveSymbolContext on the tramp.TargetOffset + tramp.TargetSection and use "ILT'" + function.GetName().


Yup, absent minded copy+paste.


This is technically wrong. It's not a "dummy" compilation unit, it's crucial for debugging incrementally linked code. SymbolFilePDB flat out fails when it hits incrementally linked code. If you're using clang+lld it's not a problem but msvc compiled code will fail. I figured I'd remove this chun of code here while removing the analogous stuff from the Native version.