[PATCH] binutils: v2: experimental use of libdiagnostics in gas

[David Malcolm]

On Tue, 2023-11-21 at 17:20 -0500, David Malcolm wrote:

[resurrecting this thread; for context the logs are at:
https://sourceware.org/pipermail/binutils/2023-November/130739.html ]

> Changed in v2:
> * updated for change from diagnostic_location_t to
>   const diagnostic_physical_location *
> * fix #if USE_DIAGNOSTICS to retain context and listing code
> 
> Output from the example below with v2 is now:
> 
> testsuite/gas/all/warn-1.s:3: warning: a warning message
>     3 |  .warning "a warning message"   ;# { dg-warning "Warning: a
> warning message" }
> testsuite/gas/all/warn-1.s:4: error: .warning argument must be a
> string
>     4 |  .warning a warning message     ;# { dg-error "Error:
> .warning argument must be a string" }
> testsuite/gas/all/warn-1.s:5: warning: .warning directive invoked in
> source file
>     5 |  .warning                       ;# { dg-warning "Warning:
> .warning directive invoked in source file" }
> testsuite/gas/all/warn-1.s:6: warning: .warning directive invoked in
> source file
>     6 |  .warning ".warning directive invoked in source file"   ;# {
> dg-warning "Warning: .warning directive invoked in source file" }
> testsuite/gas/all/warn-1.s:7: warning: 
>     7 |  .warning ""                    ;# { dg-warning "Warning: " }
> 
> and there's also now a way to toggle quoting of the source code
> (perhaps
> for use in the testsuite)
> 
> 
> Blurb from v1:
> Here's a patch for gas in binutils that makes it use libdiagnostics
> (with some nasty hardcoded paths to specific places on my hard drive
> to make it easier to develop the API).
> 
> For now this hardcodes adding two sinks: a text sink on stderr, and
> also a SARIF output to stderr (which happens after all regular
> output).

FWIW "libdiagnostics" is now "libgdiagnostics", and landed in GCC 15. 
See https://gcc.gnu.org/wiki/libgdiagnostics

I'm working on a v3 version of the patch which adds optional support
for using libgdiagnostics to "gas" and to "ld" when outputting their
diagnostics.  I demoed something a version of this at Cauldron 2024;
sorry for not posting the patches earlier, but they needed a lot of
cleanup.

Some questions:

configure.ac
============

I see that the top-level configure.ac in the binutil-gdb tree already
has a fragment beginning:

# Check for libdiagnostics support.
AC_MSG_CHECKING([whether to enable libdiagnostics])
AC_ARG_ENABLE(libdiagnostics,

Am I right in thinking this is copied from gcc?  If so, the pertinent
code is now "libgdiagnostics" rather than "libdiagnostics". 

The above test relates to whether the build of gcc should support
building libgdiagnostics.so for the host.

In terms of gas and ld, presumably we want to separately allow whether
they *use* libgdiagnostics.  So should I be patching configure.ac to
add a "--use-libgdiagnostics"?  Presumably this should default to "no".

Specifying output sinks
=======================

Since I posted the previous patches, libgdiagnostics in trunk (for gcc
16) has gained a new entrypoint:
  diagnostic_manager_add_sink_from_spec
which allows emulation of the GCC option -fdiagnostics-add-output=. 
See
https://gcc.gnu.org/onlinedocs/libgdiagnostics/topics/diagnostic-manager.html#c.diagnostic_manager_add_sink_from_spec
and
https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Message-Formatting-Options.html#index-fdiagnostics-add-output
so that in gcc you can e.g. have regular text output whilst also adding
machine-readable SARIF output via
 -fdiagnostics-add-output=sarif:file=foo.sarif
(with various other key/value pairs supported)

I tried adding this to gas and ld, but "-f" is already taken: to gas, -
f means "fast", and to ld, -f means specifying the value for
DT_AUXILIARY in elf files.

It's probably best if gas and ld used the same option for this, so is
there a good choice here?  I tried various things like e.g. -add-
diagnostic-output=,  -diagnostics-add-output=, etc, but it looks like
most of the good letters are already taken.

I should mention a wart here, which is that the "ld" support requires
adding some entrypoints to libgdiagnostics that weren't in gcc 15, and
diagnostic_manager_add_sink_from_spec is only in gcc 16 onwards.  So we
might want to require a very recent libgdiagnostics for this.  I can
provide Fedora builds it that would be helpful.

Thanks
Dave