[PATCH v3] aarch64: silence GCS warnings on shared libraries for -z gcs=implicit
Alice Carlotti
alice.carlotti@arm.com
Wed Jan 21 11:16:12 GMT 2026
On Wed, Jan 21, 2026 at 10:46:59AM +0000, Matthieu Longo wrote:
> On 20/01/2026 20:31, Alice Carlotti wrote:
> > On Mon, Jan 19, 2026 at 11:56:17AM +0000, Matthieu Longo wrote:
> > > Dynamic library incompatibilities should not be reported when no GCS
> > > option is provided (defaults to '-z gcs=implicit') and no explicit
> > > diagnostic is provided via '-z gcs-report-dynamic'.
> > >
> > > Binary Linux distributions do not rebuild all packages from scratch
> > > when rolling out a new feature or creating a new release; only
> > > modified packages get rebuilt. In the context of GCS deployment, this
> > > meant that some packages were rebuilt with GCS enabled while their
> > > dependencies were not yet GCS-compatible, resulting in warnings. These
> > > warnings caused build failures for packages that treat linker warnings
> > > as errors. Those errors slowed down the GCS deployment, and Linux
> > > distribution maintainers requested that no GCS option provided should
> > > be equivalent to '-z gcs=implicit -z gcs-report-dynamic=none'.
> > >
> > > In contrast, '-z gcs=always' should continue to report such issues by
> > > default. Warnings can still be disabled or promoted to errors by
> > > explicitly setting '-z gcs-report-dynamic' to respectively 'none' or
> > > 'error'.
> > >
> > > This patch preserves the existing behaviour for '-z gcs=never', changes
> > > the default behaviour of '-z gcs=implicit' or no GCS option, and removed
> > > the inheritance mechanism between '-z gcs-report' and '-z gcs-report-dynamics'.
> > > The expected behaviour with the different possible combinations is as
> > > follows:
> > > * -z gcs=never:
> > > No diagnostic messages are emitted.
> > > * -z gcs=implicit:
> > > No diagnostic messages are emitted for input static objects.
> > > However, if all the input static objects are marked for GCS, the
> > > output object will also be marked for GCS.
> > > In this case the output is marked with GCS, '-z gcs-report-dynamic'
> > > defaults to 'none' and no diagnostics are emitted. Diagnostics can
> > > be enabled by explicitly providing the option.
> > > * -z gcs=always:
> > > Warning diagnostics for both static and dynamic input objects are
> > > enabled by default. The two options are independent of one another,
> > > and the diagnostic level can be adjusted for each by explicitly
> > > providing the desired level to '-z gcs-report-dynamic' and '-z
> > > gcs-report'.
> > >
> > > The patch also updates the existing tests, removes redundant test cases,
> > > and adds new tests covering cases with no report option provided, or
> > > report options explicitly set.
> > This patch removes all tests for mixed inputs and '-z gcs=implicit'. I think
> > it would be appropriate to retain the the old test gcs-3-b-i.d (presumably
> > renamed to gcs-3-b.d with an adjusted #name) to cover this case.
> >
> > OK with this change.
>
> It looks to me that the case is already covered by gcs-2-b-iii.d
> #name: '-z gcs=implicit -z gcs-report=warning' with GCS-unmarked inputs emits no warnings [shared]
If I've read it correctly, none of the inputs to the new gcs-2-b-iii.d have GCS
markings. What I'm looking for is a test where some, but not all, of the
inputs have GCS markings (to verify that the logic for -z gcs=implicit is
checking that all of the inputs are marked, as opposed to checking that any of
them are marked).
>
> The only difference is '-z gcs-report=error', but if it does not emit warnings in the first place, then there are none to turn into errors, hence my assumption that gcs-2-b-iii.d is enough.
>
> Please, let me know if this makes sense.
>
> Matthieu
>
More information about the Binutils
mailing list