Page MenuHomePhabricator

Add a -gmodules option to the clang driver.

Authored by aprantl on Aug 11 2015, 1:49 PM.



This patch adds a -gmodules option to the driver and a -dwarf-ext-refs to cc1 to enable the use of external type references in the debug info (a.k.a. module debugging).

The driver expands -gmodules to "-g -fmodule-format=obj -dwarf-ext-refs" and passes that to cc1.
Most options that start with -g (e.g., -gdwarf-2) also turn on -g, and module requires object-container-wrapped modules, "-dwarf-ext-refs" been the actual low-level option for turning on external type references.

Rationale for the choice of names (and this is really all there is to review in this patch):
"-gmodules": is meant to pair nicely with "-fmodules"
"-dwarf-ext-refs": Fits into the naming scheme of similar options like "-dwarf-column-info" and "-dwarf-debug-flags". Spelling out the option "-dwarf-external-type-references" seemed to be overkill.

All this does at the moment is set a flag codegenopts. Having this flag in place is a prerequisite for emitting debug info into modules: The debug info for a module needs to use external type references for types defined in (other) modules or we would violate the minimal deserialization requirements (cf. test/PCH/check-deserializations.cpp).

Diff Detail


Event Timeline

aprantl updated this revision to Diff 31851.Aug 11 2015, 1:49 PM
aprantl retitled this revision from to Add a -gmodules option to the clang driver..
aprantl updated this object.
aprantl added reviewers: dblaikie, echristo.
aprantl set the repository for this revision to rL LLVM.
aprantl added a subscriber: cfe-commits.
rsmith added a subscriber: rsmith.Aug 19 2015, 2:15 PM
rsmith added inline comments.

Does this flag end up in the module hash? It presumably should do so.


What happens if we get a module cache hash collision between module files with different formats? This didn't really matter when the choice was essentially made per-platform, but if it's affected by a user-facing -g flag, we should make sure this works reliably. (You can probably test this by using -disable-module-hash and then using the same module with two different module formats specified.)

Maybe this is missing the point, but a hash collision between module files with different formats should be highly unlikely because we add the module format into the hash.

llvm::hash_code Hash =
  llvm::hash_combine(DirName.lower(), FileName.lower(),

Or do you mean a collision in spite of this?

  • adrian
aprantl added inline comments.Aug 20 2015, 2:45 PM

It does not get hashed:

  • If the module has no debug info, then this flag is meaningless, because it only affects the debug info output.
  • If the module has debug info, the module format is "obj" (hence a different hash) and this flag must be turned on. I will make sure this is enforced via an assertion.

[I don't see a point in having "obj" modules without debug info, If we want these, we'll need to add it to the hash.]

Alright, let's hash it, then.

aprantl accepted this revision.Apr 7 2016, 9:31 AM
aprantl added a reviewer: aprantl.

This landed a long time ago as r246192.

This revision is now accepted and ready to land.Apr 7 2016, 9:31 AM
aprantl closed this revision.Apr 7 2016, 9:31 AM