This is an archive of the discontinued LLVM Phabricator instance.

-gmodules: Don't emit incomplete breadcrumbs pointing to nonexistant PCM files.
ClosedPublic

Authored by aprantl on Feb 8 2019, 2:04 PM.

Details

Summary

When a module name is specified as -fmodule-name, that module gets a
clang::Module object, but it won't actually be built or imported; it
will be textual. CGDebugInfo wouldn't detect this and them emit a
DICompileUnit that had a hash but no name and that confused both
dsymutil, LLDB, and myself.

rdar://problem/47926508

Diff Detail

Event Timeline

aprantl created this revision.Feb 8 2019, 2:04 PM
JDevlieghere accepted this revision.Feb 8 2019, 3:08 PM

This makes sense to me, just one nit.

lib/CodeGen/CGDebugInfo.cpp
2304

Maybe it's just me but I had to reread this sentence a few times to be sure what you meant by the double negation. Maybe clang module without ASTFile must be specified by -fmodule-name is easier to grok.

This revision is now accepted and ready to land.Feb 8 2019, 3:08 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptFeb 8 2019, 3:16 PM

This, I guess, is part of the impact of moving towards explicit modules (-fmodule-name is for building a module with that name, right?)?

With explicit modules there is the option for modular code generation - which doesn't require any specific DWARF consumer support (so should "just work" - if you've a build system you can teach to generate a .o file from the .pcm, and link that .o with everything else)

This, I guess, is part of the impact of moving towards explicit modules (-fmodule-name is for building a module with that name, right?)?

That option is overloaded. It's used to specify the name of an explicit modules too, but in this context particularly it is used to specify that clang is compiling the Framework that defines the module with that name, which has the effect of *not* building the module of that name as a clang module even though -fmodules was specified and every other module is built as a module. This is necessary for developing Frameworks that are part of the macOS SDK to avoid accidentally include the module from the OS instead of the one being developed. That's a quite specific use-case.

With explicit modules there is the option for modular code generation - which doesn't require any specific DWARF consumer support (so should "just work" - if you've a build system you can teach to generate a .o file from the .pcm, and link that .o with everything else)

Different can of worms, I believe.

This, I guess, is part of the impact of moving towards explicit modules (-fmodule-name is for building a module with that name, right?)?

That option is overloaded. It's used to specify the name of an explicit modules too, but in this context particularly it is used to specify that clang is compiling the Framework that defines the module with that name, which has the effect of *not* building the module of that name as a clang module even though -fmodules was specified and every other module is built as a module. This is necessary for developing Frameworks that are part of the macOS SDK to avoid accidentally include the module from the OS instead of the one being developed. That's a quite specific use-case.

With explicit modules there is the option for modular code generation - which doesn't require any specific DWARF consumer support (so should "just work" - if you've a build system you can teach to generate a .o file from the .pcm, and link that .o with everything else)

Different can of worms, I believe.

Ah, fair enough - thanks for the context!