[PATCH v1 0/4] [RFC] Provide a target-specific definition to enable/disable section of code in others modules than gas

Jan Beulich jbeulich@suse.com
Thu Dec 12 10:25:03 GMT 2024


On 11.12.2024 13:05, Matthieu Longo wrote:
> **Disclaimer:** This patch series is related to a comment from another patch series (see [1]), and tries to propose a solution for the raised issue. Hence the code changes in patch 3/4 are restricted to architecture-specific code for DWARF and CFI directives.
> 
> DWARF 5 standard provides a space for vendor-specific DWARF directives. Binutils currently defines GNU-specific DWARF directives and vendor-specific ones for AArch64, SGI/MIPS, and Sparc architectures.
> The architecture specific code is not guarded. This has caused confusion in the past, and .cfi_window_save (a Sparc-specific directive) was used on AArch64 in place of .cfi_negate_ra_state recommended by the document for DWARF extensions on AArch64 (see [2]). In [1], Jan Beulich rightly pointed out the issue and proposed to introduce an `#ifdef TC_AARCH64` around the AArch64 directives.
> However, the current config header file generated by autotools does not provide everywhere a "switch mechanism" to enable/disable those extensions depending on the selected target similar to the one implemented in the gas module via `TC_<arch>`.
> 
> * Patch 1/4 adds the boilerplate to add the `TC_<arch>` definition to all modules of binutils interacting with architecture-specific DWARF
> directives, i.e. bfd, binutils, gprofng, libbacktrace, libiberty.
> Note: I added `CI-tag: skip` to the description of the commit so that the CIs or bisecting tools can skip it as it requires the autotools files to be regenerated.

As Alan has already pointed out, what is doable in gas cannot easily be extended
in the same shape to libraries potentially serving many targets. My suggestion
was never meant to go beyond gas.

Jan



More information about the Binutils mailing list