This parses entries in pecoff import tables for imported DLLs and
is intended as the first step to allow LLDB to load a PE's shared
modules when creating a target on the LLDB console.
Details
Diff Detail
Event Timeline
If you plan to invest in more substantial changes in ObjectFilePECOFF, it might worth considering a complete re-write in terms of llvm::object::coff. It has pretty comprehensive support for the PE/COFF spec, so it's just a matter of implementing ObjectFilePECOFF on top of it.
source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp | ||
---|---|---|
857 | Does this actually need to be a recursive_mutex? |
source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp | ||
---|---|---|
857 | I think there is access to the member 'm_filespec_ap'. | |
909 | Given no valid UUID for PECOFF for now, you can't get a valid image based on a filename only. For example, $ ldd main.exe ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffc5e070000) KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ffc5ddb0000) KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ffc5ad00000) DllB.dll => /c/DllB.dll (0x7ffc31450000) DllA.dll => /c/DllA.dll (0x7ffc2f7b0000) ./lldb.exe main.exe (lldb) image list [ 0] C:\main.exe However we expect 3 images at the moment (excluding windows system libraries) ./lldb.exe main.exe (lldb) image list [ 0] C:\main.exe [ 1] C:\DllA.dll [ 2] C:\DllB.dll So it will be better to have full path of the imported modules here. |
source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp | ||
---|---|---|
848–851 | I'm afraid of a race condition here. It seems we can occur here in different threads simultaneously (due to the mutex lock at the line 810), but it is not thread-safe to change and read same unique_ptr in different threads simultaneously. It is safe to move it between threads, but it's not the case. I would guard all actions on unique_ptr with the mutex. | |
907–914 | Also consider the following scenario: Thread A: GetDependentModules -> ParseDependentModules -> e.g. line 837, idx is greater than 0, but less than num_entries; | |
1126–1130 | The same situation as I've described above. |
Still didn't get a clear answer if the mutex being used needs to be recursive. If it doesn't, perhaps std::mutex can be used instead of std::recursive_mutex? Not everyone agrees with me, but I often prefer to be too strict rather than too relaxed.
Zach: yes the module mutex needs to be recursive. Plenty of places where the symbol file stuff can call other symbol file APIs. To avoid A/B locking issues, the lldb_private::Module, lldb_private::ObjectFile and lldb_private::SymbolVendor and lldb_private::SymbolFile all use the module mutex.
drive by CR notes:
- does this handle forwarding imports? (it doesn't seem to from a quick glance at the code)
- can you please add, or extend the existing test to cover the transitive case? A simple dag would suffice (ex. make both dllA and dllB implicitly import dllC)
source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.h | ||
---|---|---|
215 | nit: either explicitly assign values to all or none |
It sounds like at least part of this could be tested by adding the ability to dump dependent modules to lldb-test object-file (which I think would fit very nicely within the current information printed by that command). I seem to recall seeing code like that in some patch but it seems to be missing here now.
The ability to dump dependent modules is in another review that is waiting on this one.
https://reviews.llvm.org/D53096
Could we reverse the dependencies between the two? I.e., first add the necessary functionality to lldb-test and then write the test using that? Or just merge that into a single patch?
Some of the information tested here is already available there (list of sections) other can be added easily (list of symbols).
Thanks for adding the test. looks good to me.
source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.h | ||
---|---|---|
289–291 | Consider using Optional<T> instead of unique_ptr to reduce pointer chasing. Also, do these have to be mutable? I was expecting that you needed to lazy-initialize them from some const member, but I couldn't find any evidence of that... |
Hello,
This PR broke the green dragon bots, see the following log file:
I was about to revert it but it looks @stella.stamenova landed a fix that looks good:
http://llvm.org/viewvc/llvm-project?view=revision&revision=348542
Please watch the bots after you land a change.
nit: either explicitly assign values to all or none