From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120225 invoked by alias); 16 Apr 2018 01:36:38 -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 120209 invoked by uid 89); 16 Apr 2018 01:36:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=solved, H*c:alternative, office, our X-HELO: mail-qt0-f176.google.com Received: from mail-qt0-f176.google.com (HELO mail-qt0-f176.google.com) (209.85.216.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 16 Apr 2018 01:36:35 +0000 Received: by mail-qt0-f176.google.com with SMTP id s2so13733079qti.2 for ; Sun, 15 Apr 2018 18:36:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=x9/XDXtRdAop3R9ZLvYCcNOp4xJ8xUMVbPFWqHotXVU=; b=I3cUP+LiZZu1+D8VRemkeXRFH2x7APyme0UWti2YmQhWPYUJFxYcKJRcu8Pn+OXQyP K61P6r4sjvvq4yzhzeIbgzR7R/F5tVgsiuTH+qWF7VerAKIwpXztgPwY40M5CS8v+nkp AUVWSfNpZ6N+klvn5WJIU/ijKBdvKBm5IPFz4UR6YfOe+GLH5tvGsKDUAvhu6ahVc2OR +/GCdKa7LHWIyYWWGLzSYGPhLoaxFL9hN6PGuOs3mN/eltRUbMTd89e+XLm+6cQ+RExP Z7I2m/qp5+cnaZuzs8RGnIAvxT7nKvhpc/uoDyxn7C2rfgOOxA1vJYqqzWKYb60cmjhF cJTw== X-Gm-Message-State: ALQs6tC3GDStOyWC7CVeYXabUpBAmZ4Gxa6eadLPKlTFMfo3RplwYfNI +8xDcJl2JovgKpuiWqQHOMccZGLf+GBPSI0uqWn32A== X-Google-Smtp-Source: AIpwx49cQQSBTaUMfjVCYb4bCEOVU322Gkby0NDc/4ORsPu7+zpBez5bH03+uVE+dw8HSg+dsyWRPU/OTt6UG9PCO/g= X-Received: by 10.237.61.213 with SMTP id j21mr13509150qtf.251.1523842594109; Sun, 15 Apr 2018 18:36:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.46.149 with HTTP; Sun, 15 Apr 2018 18:36:03 -0700 (PDT) In-Reply-To: <061e956c-72a7-2c2e-512b-3dfe42881818@redhat.com> 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> <061e956c-72a7-2c2e-512b-3dfe42881818@redhat.com> From: Omair Javaid Date: Mon, 16 Apr 2018 01:36:00 -0000 Message-ID: Subject: Re: [PATCH 0/3 v3] [AArch64] Support tagged pointer To: Pedro Alves Cc: Yao Qi , GDB Patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-04/txt/msg00301.txt.bz2 On 11 April 2018 at 23:27, Pedro Alves 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. ^ Does this make sense? For Linux Kernel Debugging we have separate OSABI (LINUX_KERNEL). Patch snippet from LKD patches by Phillip given below: +static enum gdb_osabi +s390_lk_osabi_sniffer (bfd *abfd) +{ + if (bfd_get_section_by_name (abfd, ".reg-s390-prefix") + || bfd_get_section_by_name (abfd, "__ksymtab")) + return GDB_OSABI_LINUX_KERNEL; + + return GDB_OSABI_UNKNOWN; +} + +extern initialize_file_ftype _initialize_s390_lk_tdep; /* -Wmissing-prototypes */ + +void +_initialize_s390_lk_tdep (void) +{ + /* Hook us into the OSABI mechanism. */ + gdbarch_register_osabi (bfd_arch_s390, bfd_mach_s390_64, GDB_OSABI_LINUX_KERNEL, + s390_lk_init_abi_64); + /* Add OSABI sniffer. */ + gdbarch_register_osabi_sniffer (bfd_arch_s390, bfd_target_elf_flavour, + s390_lk_osabi_sniffer); + + /* Initialize the Linux kernel target descriptions. */ + initialize_tdesc_s390x_cr_linux64 (); + initialize_tdesc_s390x_vxcr_linux64 (); +} Thanks, > Pedro Alves >