That's ok by me. Would you like to clarify what Thiago needs to do so we
don't send mixed signals then?

Thanks

On Sun, Feb 22, 2026, 14:22 Simon Marchi <simark@simark.ca> wrote:

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