From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53809 invoked by alias); 19 Oct 2017 10:51:59 -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 53760 invoked by uid 89); 19 Oct 2017 10:51:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=complains, H*r:sk:static. X-HELO: mail-wr0-f196.google.com Received: from mail-wr0-f196.google.com (HELO mail-wr0-f196.google.com) (209.85.128.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 19 Oct 2017 10:51:57 +0000 Received: by mail-wr0-f196.google.com with SMTP id g90so7844623wrd.6 for ; Thu, 19 Oct 2017 03:51:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=3+M9WcNlyd6ODymUihdObUf02OE9v55iCeDcaRemRt0=; b=Tn+mtr+AyZ27aQ8IMaUkD/GYdbCZ/cc3M+PrUa4JbNswDEoDuSm98K/EDixE/X//2Q 9S5472B8zUjNvcQ5i3v05cTJGqpXUvZkecQ2hq2SoPPuoJUgaRDg2nVymURx0FGwAfEO JCEs7xSFewXQERFH4DPdkUqYo8Ac+4ZNmpsK646VdP8ODtArRChji0kbKRScfX1UiWDj n4f0K6svsvYL/3SG7rIhnEJbKaL10RapRqyXGuJcJhamYZtcdieADV8lLrQv3GjXN3hP ZhJrQ6uioVhpYMkpsQn+hBXzl09PHCy31Jm/wEa+0SV2B42NQ3jZPpEaUK2vlfYzXJzF DEQg== X-Gm-Message-State: AMCzsaXeEqANYfNO9QNN7x34AvZD23uKuDq2/6YII4xDJJpjMNSDrqrs t43QIk2TiW9yoreegoVltnTAIw== X-Google-Smtp-Source: ABhQp+SW6kfZi4Go8f0zYz67PXhqGWb79Bld/VKUh6cjvHM7PYGVq4v/EkuSkmZTImTRIDfiyDya1w== X-Received: by 10.223.198.134 with SMTP id j6mr1124955wrg.213.1508410314542; Thu, 19 Oct 2017 03:51:54 -0700 (PDT) Received: from E107787-LIN (static.42.136.251.148.clients.your-server.de. [148.251.136.42]) by smtp.gmail.com with ESMTPSA id q74sm5940127wrb.51.2017.10.19.03.51.53 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Thu, 19 Oct 2017 03:51:53 -0700 (PDT) From: Yao Qi To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] [AArch64 Linux] Get rid of top byte from tagged address References: <1508400527-20718-1-git-send-email-yao.qi@linaro.org> <561ea277-4b4c-ae82-01e1-1cde96cb54f2@redhat.com> Date: Thu, 19 Oct 2017 10:51:00 -0000 In-Reply-To: <561ea277-4b4c-ae82-01e1-1cde96cb54f2@redhat.com> (Pedro Alves's message of "Thu, 19 Oct 2017 10:52:20 +0100") Message-ID: <86po9jv29n.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg00600.txt.bz2 Pedro Alves writes: > I'm fine with doing this if it's what arm/linaro folks want, > though personally (with absolutely no experience in this) I have > reservations about whether stripping the top byte in the special > case of memory accesses is a good idea, since it may puzzle folks > when they pass such pointers/addresses in registers/structures and > things don't magically work then (and then gdb masks the problem when > folks try to diagnose it, as in "but I can access the object > via "p *s->ptr", why isn't this working??? bad gdb."). > > So I think this should be documented in the manual somewhere. I don't understand how does GDB affect the program. ARMv8 architecture supports tagged address for data values, and top byte of virtual address is ignored in some cases, struct s s1; s1.i =3D 1234; struct s *p1 =3D &s1; struct s *p2 =3D &s1; uint64_t t =3D (uint64_t) p2; t |=3D 0xf000000000000000ULL; p2 =3D (struct s *) t; printf ("%p %d\n", p2, p2->i); The program output is "0xf000ffffc2e51720 1234". However, linux kernel applies an restriction that top one byte should be zero when user space passes address to syscall or access /proc file system. When GDB debugs inferior, it needs to either pass address to kernel through syscall (ptrace) or access /proc, kernel complains on the address. The point of this patch is to keep tagged bits in VA, and only get rid of them at the point when the address is to be passed to kernel. GDB has no problem debugging the example above, (gdb) p p2 $1 =3D (struct s *) 0xf000fffffffff500 (gdb) p *p2 $2 =3D {i =3D 1234} (gdb) p p2->i $3 =3D 1234 --=20 Yao (=E9=BD=90=E5=B0=A7)