Hi David, On 2023-11-21 22:20, David Malcolm wrote: > Here's v2 of the "libdiagnostics" shared library idea; see: > https://gcc.gnu.org/wiki/libdiagnostics > > As in v1, patch 1 (for GCC) shows libdiagnostic.h (the public > header file), along with examples of simple self-contained programs that > show various uses of the API. > > As in v1, patch 2 (for GCC) is the work-in-progress implementation. > > Patch 3 (for GCC) adds a new libdiagnostics++.h, a wrapper API providing > some syntactic sugar when using the API from C++. I've been using this > to "eat my own dogfood" and write a simple SARIF-dumping tool: > https://github.com/davidmalcolm/libdiagnostics-sarif-dump > > Patch 4 (for GCC) is an internal change needed by patch 1. > > Patch 5 (for GCC) updates GCC's source printing code so that when > there's no column information, we don't print annotation lines. This > fixes the extra lines seen using it from gas discussed in: > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635575.html > > Patch 6 (for binutils) is an updated version of the experiment at using > the API from gas. > > Thoughts?
Do you have plans on making this a top level library instead? That would allow easily making it a non-optional dependency for binutils, as we could have the library in the binutils-gdb repo as well, for instance. From the Cauldron discussion I understood that the diagnostics stuff doesn't depend on much of GCC's data structures, and doesn't rely on the garbage collector. Is there something preventing that? (Other than "it's-a-matter-of-time/effort", of course.) Pedro Alves
