[PATCH] D108261: [DebugInfo] Fix end_sequence of debug_line in LTO Object

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

> Thanks for comments! I roughly get your points but may need sometime to digest it.
> I may misunderstand an important piece on your example -- CU1:func1:.text, then CU2:func2:.text, then CU1:func3:.text.
> My understanding is CU is a compilation unit which seems to be processed sequentially (in LLVM).

Ah, that's not quite correct - a CU exists both by its existence in the cu list named module metadata, and by its reference from DISubprograms (which exist by reference from llvm::Functions). A CU is not processed atomically - some handling is done up front (at the start of the module, iterating the named module metadata list of CUs) and some is done at the end of the module - but between those, for all the DISubprograms, they're visited in the order of the llvm::Functions that reference them - so they can be arbitrarily interleaved.

> How could we interleave CUs like this? I thought we only interleave sections within a CU.
> Does this interleaving come from a ThinLTO compilation? I would appreciate it if you can provide an example.

I don't know that I have a concrete example that creates the interleaving I can reproduce by hand - but it's not an IR invariant that all Functions that reference CUs through DISubprograms must be contiguous for that CU.

To create such a situation by hand, create two files, let's say `a.cpp` and `b.cpp` and have two functions `a1` and `a2` in `a.cpp` and `main` in `b.cpp`, have `main` call `a1` and `a2`. Compile to IR, link the IR, hand-modify the IR to reorder the functions so it goes `a1`, then `main`, then `a2` - then you should be able to reproduce/see the strange situation where the line table for `a.cpp` continues/extends over `main`/`b.cpp`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108261/new/

https://reviews.llvm.org/D108261