[PATCH] D28005: Add a unit field to DIGlobalVariable, mirroring the design of DISubprogram.
David Blaikie via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Jan 3 14:01:36 PST 2017
dblaikie added inline comments.
================
Comment at: docs/SourceLevelDebugging.rst:452
+ the variable's DICompileUnit. If the global symbol the variable is attached
+ to is linkonce_odr, and the compile unit the global variable gets emitted
+ into doesn't matter, the DIGlobalVariable may instead be unique (i.e., not
----------------
Probably could omit the reference to linkonce_odr and let the rest of the definition stand.
That way if anything were to duplicate other globals (eg: thinlto might import globals, etc) they could/would use this functionality as well, potentially.
================
Comment at: docs/SourceLevelDebugging.rst:456-458
+2. *Constant definitions* are reachable via the DICompileUnit's list of globals
+ which points to a DIGlobalVariableExpression with a DIGlobalVariable without
+ a unit field and a DIExpression describing a constant value.
----------------
Is this true? Do we go and change the DIGlobalVariable if we collapse an llvm::GlobalValue into a constant? So that it doesn't have a unit field anymore? I assume we don't do that, so some constants might point to DIGlobalVariables with a non-null unit field.
================
Comment at: docs/SourceLevelDebugging.rst:460-461
+
+3. *Declarations* are DIGlobalVariables without a unit field that are only
+ reachable via a DIImportedEntity and have isDefinition set to false.
+
----------------
Is this correct? If all DIGlobalVariables referenced by DIImportedEntities can have no unit field (& thus be emitted into any unit that references them) - should any DIGlobalVariables have unit fields?
https://reviews.llvm.org/D28005
More information about the llvm-commits
mailing list