In rL302576, DISubprograms gained the constraint that a !dbg attachments to functions must
have a 1:1 mapping to DISubprograms. As part of that change, the function cloning support
was adjusted to attempt to enforce this invariant during cloning. However, there
were several problems with the implementation. Part of these were fixed in rL304079.
However, there was a more fundamental problem with these changes, namely that it
bypasses the matadata value map, causing the cloned metadata to be a mix of metadata
pointing to the new suprogram (where manual code was added to fix those up) and the
old suprogram (where this was not the case). This mismatch could cause a number of
different assertion failures in the DWARF emitter. Some of these are given at
https://github.com/JuliaLang/julia/issues/22069, but some others have been observed
as well. Attempt to rectify this by partially reverting the manual DI metadata fixup,
and instead using the standard value map approach. To retain the desired semantics
of not duplicating the compilation unit and inlined subprograms, explicitly freeze
these in the value map.
Details
Details
Diff Detail
Diff Detail
- Build Status
Buildable 6846 Build 6846: arc lint + arc unit
Event Timeline
Comment Actions
Looks good from a coroutine side. Though I am not fluent in DebugInfo to LGTM the whole change.
One comment about "ModuleLevelChanges" parameter.
Is the description of that parameter accurately captures its purpose?
Namely:
/ If ModuleLevelChanges is false, VMap contains no non-identity GlobalValue
/ mappings.
Comment Actions
Well, note really, but that's sort of separate from this revision. A more accurate (though IMO still slightly confusing) description is the one that's on the flag:
/// If this flag is set, the remapper knows that only local values within a /// function (such as an instruction or argument) are mapped, not global /// values like functions and global metadata. RF_NoModuleLevelChanges = 1,
Comment Actions
Thanks Keno, this appears to be a far better approach. The only question that remains is whether / how to update the linkage name of the cloned DISubprogram. But I don't think that this needs to be solved in this patch.