[PATCH] Teach CC1 to dump module dependencies to a directory

Justin Bogner mail at justinbogner.com
Wed Jun 18 19:37:58 PDT 2014


Ben Langmuir <blangmuir at apple.com> writes:
>     On Jun 18, 2014, at 9:11 AM, Argyrios Kyrtzidis <kyrtzidis at apple.com>
>     wrote:
>
>         On Jun 18, 2014, at 1:08 AM, Justin Bogner <mail at justinbogner.com>
>         wrote:
>        
>         Thanks for the feedback!
>        
>         Argyrios Kyrtzidis <kyrtzidis at apple.com> writes:
>        
>             Thank you for your work on this.
>            
>             Some high level comments first; the way ModuleDependencyCollector
>             is
>             getting hooked up, results in:
>            
>             - If no module needs building (because module cache has it) no
>             module
>             dependency is getting written out
>
>         I realize this, but as far as I can tell there isn't really a
>         practical
>         way to get all of the module dependencies except for when we actually
>         create a module. Unless there's a way to extract this information from
>         an imported ModuleFile that I've missed, I think we need to collect
>         this
>         information as we parse the AST to build a module in the first place.
>        
>         If there is a more reliable way to do this, I'm all ears. I should
>         mention though, for the purposes of getting more useful crash reports
>         with modules this limitation isn't very important. Notably, it's
>         useful
>         to collect the .pcm files anyway, and using a fresh cache directory is
>         a
>         very simple way to do that.
>
>             - It doesn’t hook in the top level module, e.g. if I have "@import
>             Darwin;” then no module dependency is written out even if the
>             module
>             cache is empty.
>
>         This seems like a bigger problem, and I don't really understand it.
>         Where is the module built? I'm pretty convinced that the place I've
>         hooked into is the only one that creates a CompilerInstance with
>         BuildingModule set to true…
>
>     Ben, could you help out on hooking up ModuleDependencyCollector in a way
>     that will address the above ?
>
> Sure!  The problem is that the first time we come to attempt loading a
> top-level module (before it is compiled), we will be here and not attach
> anything since ModuleDepCollector hasn’t been filled in yet.
>
>     +    if (ModuleDepCollector)
>     +      ModuleDepCollector->attachToASTReader(*ModuleManager);
>
> If you call ModuleDepCollector = getModuleDepCollector() before that if, it
> works for me.

Okay, since ModuleDepCollector needs to have the same lifetime as the
top-level CompilerInstance, it makes more sense to create it during
CreatePreprocessor along with the other DependencyOption stuff. This is
a bit nicer in that it makes getModuleDepCollector a bit less special,
but it does mean that this feature doesn't interoperate well with
-fdisable-free, which is unfortunate.

I've attached an updated patch. I've rolled the VFS map generation into
the main patch, as it didn't make much sense to do it separately. I've
also added some tests and added handling for path traversal (ie,
bin/../lib). Also attached an up to date patch for llvm implementing
copy_file.

What do you think?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: clang-0001-Frontend-Add-a-CC1-flag-to-dump-module-dependencies.3.patch
Type: text/x-patch
Size: 15499 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140618/e011f8d6/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-0001-Support-Add-llvm-sys-fs-copy_file.2.patch
Type: text/x-patch
Size: 2279 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140618/e011f8d6/attachment-0001.bin>


More information about the cfe-commits mailing list