On 2026-02-22 05:06, Luis wrote:
> I don´t recall the discussions touching renaming/moving of these
> constants. But I see your point. I just don´t think we should block
> this series from going in on that particular snag. We should try a
> refactoring as a follow on.
>

This is what I was referring to, from Thiago:

    Ok. While fixing this, I noticed that gdb/arch/aarch64-gcs-linux.h also
    contains:

      /* Feature check for Guarded Control Stack.  */
      #ifndef HWCAP_GCS
      #define HWCAP_GCS (1ULL << 32)
      #endif

    which can be said to be an implicit dependency on an arch-specific
    include file (since it relies on such file defining or not HWCAP_GCS).

    Also, on non-AArch64 systems it relies on them not having by coincidence
    an unrelated hardware capability bit also named HWCAP_GCS...

    I fixed this in v2 by renaming the macro to AARCH64_HWCAP_GCS and
    defining it unconditionally (following the existing example of
    AARCH64_HWCAP_PACA).

From: https://inbox.sourceware.org/gdb-patches/87qzqkx8l1.fsf@linaro.org/T/#mbe0d3d5a2802f4f88abe907874ed44c063666639

I think that was a good idea, and it seems like we went backwards from
there?

> On the naming, I don´t mind adding an AARCH64 prefix, but I find it
> unlikely we will run into a naming collision given BSD uses equivalent
> constants. Again, not disputing the matter of what is technically
> correct or not.

This is already a refactoring / cleanup series, it's not harder to do it
right from the start.

Simon