[PATCH] D138869: [Docs][RFC] Add AMDGPU LLVM Extensions for Heterogeneous Debugging

Paul Robinson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 29 14:23:22 PST 2022


probinson added a comment.

> the "heterogeneous" naming has only persisted because we haven't divined a better name for the work as a whole

Yeah, "variable location tracking debug-info metadata redesign" isn't too snappy.

> it is currently always "correct" to drop debug information. This is probably something that warrants a broader discussion, as that is admittedly a pretty unhelpful approach for anyone actually relying on these upgrades for anything with debug information,

That has been the historical attitude, which I blame on the academic roots of the project lo these many years ago, and is totally inappropriate for an industry product used by huge numbers of people for their daily work.

> but I don't see the use case for upgrading debug info in bitcode at rest.

Your examples look like they're based on using debug info for source-level debugging by the end user. The vast majority of end users don't do any debugging, but there are lots of cases where what they're getting from the vendor is bitcode. Shipping bitcode libraries to facilitate LTO is a thing, and I can easily imagine a core dump coming back to the library provider, who will indeed have the source available.  iOS apps are delivered to the app store as bitcode, and aren't necessarily re-delivered with every compiler update; yet an app crash surely wants to have source information reported back to the vendor if at all possible.  Crash dump backtraces want debug info not just for source info but to allow symbolizing the trace, deducing parameters, and the like.

So, when Clang reads older bitcode, it definitely needs to upgrade debug info metadata on the fly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138869



More information about the llvm-commits mailing list