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

[Jan Beulich]

On 09.07.2025 00:05, David Malcolm wrote:
> 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". 

Most (all?) top-level stuff is generally (intended to be) shared, yes.

> 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.

But in both you could make these "standalone" long options, without
implying that -f... is generally a short option with a required argument?
At least in gas long options also permit for the alternative spelling
with just a single leading dash, iirc. Not sure though whether that
would conflict with the short-form "-f". Probably not, seeing that
several targets also have -fpic.

Jan