From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15143 invoked by alias); 11 Apr 2018 18:27:54 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 15133 invoked by uid 89); 11 Apr 2018 18:27:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=Hx-languages-length:754, HContent-Transfer-Encoding:8bit X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 11 Apr 2018 18:27:53 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3891E8185321; Wed, 11 Apr 2018 18:27:52 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6E3DC1208F7B; Wed, 11 Apr 2018 18:27:51 +0000 (UTC) Subject: Re: [PATCH 0/3 v3] [AArch64] Support tagged pointer To: Omair Javaid References: <1512727471-30745-1-git-send-email-yao.qi@linaro.org> <5429b7f0-ee91-67f4-3b15-f5de9aa06389@redhat.com> <5e21c13b-9261-f947-e06c-dad9568278bf@redhat.com> Cc: Yao Qi , GDB Patches From: Pedro Alves Message-ID: <061e956c-72a7-2c2e-512b-3dfe42881818@redhat.com> Date: Wed, 11 Apr 2018 18:27:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2018-04/txt/msg00220.txt.bz2 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. Thanks, Pedro Alves