Re: [AArch64][6/6] Core file support for "pauth" feature

[Pedro Alves <palves@redhat.com>]

On 08/10/2017 10:22 PM, Yao Qi wrote:
> On 17-08-10 12:08:36, Pedro Alves wrote:
>>> +#ifndef HWCAP_APIA
>>> +/* AArch64 GNU/Linux HWCAP values.  These should be synced with kernel
>>> +   definitions.  */
>>> +#define HWCAP_APIA (1 << 16)
>>> +#endif
>>
>> Re. the #ifndef, consider that tdep.h files are included in cross
>> debugger builds.  E.g., an x86-hosted gdb cross debugging aarch64.
>> Some archs have "namespaced" names like the s390 mips, sparc, etc.
>> (e.g., HWCAP_S390_VX) which avoids the case of the names being defined
>> on host/target with a different meanings/values, but not all do.
>> But even with such names, we always have to provide fallback definitions
>> for cross debuggers.  And with that all in mind, and since you're defining
>> fallbacks anyway, how about unconditionally defining/using our
>> own conflict-resistant versions, like AARCH64_HWCAP_APIA?
>>
> 
> I am inclined to use the same macro name as kernel uses.  These macros are
> only used in $arch-linux-{tdep,nat}.c, so it is clear that the macros
> are about architecture $arch.

I think there's a misunderstanding.  It's not about clarity -- if HWCAP_APIA
is defined on a !Aarch64 host as some value other than "(1 << 16)", then
this:

> +++ b/gdb/aarch64-linux-tdep.c
>  
> -  return tdesc_aarch64;
> +  return aarch64_hwcap & HWCAP_APIA ? tdesc_aarch64_pauth : tdesc_aarch64;
>  }

will silently compile to use wrong value.

Might never happen in practice, but why write a potential problem,
_particularly since you already have to write the fallback
macro anyway_?  What's the advantage of not doing what I suggested?

It'd be different if the macro was _only_ used in a -nat.c
file, but then I'd object to defining it in the -tdep.h file.

Thanks,
Pedro Alves