[AArch64][6/6] Core file support for "pauth" feature
Pedro Alves
palves@redhat.com
Thu Aug 10 21:32:00 GMT 2017
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
More information about the Binutils
mailing list