Re: [PATCH 0/3 v3] [AArch64] Support tagged pointer

[Pedro Alves <palves@redhat.com>]

On 04/16/2018 02:36 AM, Omair Javaid wrote:
> On 11 April 2018 at 23:27, Pedro Alves <palves@redhat.com> wrote:
> 
>> On 04/11/2018 12:59 PM, Omair Javaid wrote:
>>
>>> Yes I can submit a patch that enables set_gdbarch_significant_addr_bit
>> for aarch64-linux-tdep only.
>>>
>>> But a point to discuss here is the use-case where some people use
>> *-linux-gdb for debugging seamlessly between kernel and user-space.
>>>
>>> There can be ways we can distinguish between user/kernel address space
>> and clear or set top byte of the address even in case of linux targets.
>>>
>>> Does this sound something we should do?
>>
>> Yeah, why not.
>>
>> What are the pending kernel debugging patches using to distinguish
>> userspace and kernel debugging modes?  Off hand, I'd think we'd want to
>> make those separate ABIs / osabis / gdbarchs.
>>
> 
> Sorry for late reply on this I am out of office this week.
> 
> I have given this a thought and I propose to do the following:
> 
> Turn on pointer tagging on OSABI (LINUX) by default.
> 
> Add commands set aarch64 pointer-tagging show/enable/disable.
> 
> Once LKD patches for aarch64/arm land in our need for this will
> automatically be solved.

Makes sense, but I'd like to clarify usefulness of the separate
"set aarch64 pointer-tagging" command.
If indeed we're doing to end up with a separate osabi for the Linux
kernel, then "set osabi linux-kernel" will result
in disabling pointer-tagging too.  So, will it still be useful to have
the specific "set aarch64 pointer-tagging" commands?  Do you see
use cases for "set aarch64 pointer-tagging" beyond disabling it
for Linux kernel debugging?  I'm thinking that it may be useful
for bare metal debugging.  But, ideally, GDB would figure it out
on its own without user intervention.  Is there's some bit in some
register gdb could read that indicates whether tagging is enabled?

Thanks,
Pedro Alves