From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 37679 invoked by alias); 18 Nov 2015 18:18:39 -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 37650 invoked by uid 89); 18 Nov 2015 18:18: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,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: e06smtp06.uk.ibm.com Received: from e06smtp06.uk.ibm.com (HELO e06smtp06.uk.ibm.com) (195.75.94.102) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Wed, 18 Nov 2015 18:18:36 +0000 Received: from localhost by e06smtp06.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 18 Nov 2015 18:18:33 -0000 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp06.uk.ibm.com (192.168.101.136) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 18 Nov 2015 18:18:31 -0000 X-IBM-Helo: d06dlp03.portsmouth.uk.ibm.com X-IBM-MailFrom: uweigand@de.ibm.com X-IBM-RcptTo: gdb-patches@gcc.gnu.org Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 2CC061B0804B for ; Wed, 18 Nov 2015 18:18:51 +0000 (GMT) Received: from d06av11.portsmouth.uk.ibm.com (d06av11.portsmouth.uk.ibm.com [9.149.37.252]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id tAIIIVGl6226358 for ; Wed, 18 Nov 2015 18:18:31 GMT Received: from d06av11.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av11.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id tAIIIUIU020870 for ; Wed, 18 Nov 2015 11:18:30 -0700 Received: from oc7340732750.ibm.com (dyn-9-152-213-152.boeblingen.de.ibm.com [9.152.213.152]) by d06av11.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id tAIIIUHW020864; Wed, 18 Nov 2015 11:18:30 -0700 Received: by oc7340732750.ibm.com (Postfix, from userid 500) id 6FC3E8509; Wed, 18 Nov 2015 19:18:30 +0100 (CET) Subject: Re: [PATCH 0/3] Support for x86 segments as address classes To: rth@redhat.com (Richard Henderson) Date: Wed, 18 Nov 2015 18:18:00 -0000 From: "Ulrich Weigand" Cc: palves@redhat.com (Pedro Alves), gdb-patches@gcc.gnu.org In-Reply-To: <563B646D.7000805@redhat.com> from "Richard Henderson" at Nov 05, 2015 03:15:09 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20151118181830.6FC3E8509@oc7340732750.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15111818-0025-0000-0000-000004F1937D X-SW-Source: 2015-11/txt/msg00377.txt.bz2 Pedro Alves wrote: > get_current_frame / get_current_regcache ? If you can pass it down > through a couple layers, it's of course better. > > Though I'm not sufficiently familiar with the address class > mechanisms be to sure I'm not pointing you in the > wrong direction. Ulrich, can you help? Sorry for the late reply, I must haved missed this earlier ... I'm a bit sceptical about using get_current_regcache in the gdbarch_address_to_pointer routines. Those routines are called from the generic unpack_long / pack_long routines, which in turn are called from all over the source base. It is at least not immediately obvious to me that all those call sites will have an appropriate "current" regcache set. (It is probably the case most of the time, though ...) I had a similar issue on the SPU, where I'm using those routines to encode the SPU ID into the GDB CORE_ADDR. For a while, I was attempting to get the SPU ID to use from the "current" regcache as well, but then decided on another approach: create a separate gdbarch structure for each SPU ID in use, and take the SPU ID from gdbarch->tdep in gdbarch_address_to_pointer. This worked because I was able to already identify the appropriate SPU ID whenever creating an gdbarch (from the objfile, or for the current thread). This method likely will not work for the x86 case. Richard Henderson wrote: > Breakpoint 2, test () at z.c:10 > 10 return *f + *g; > (gdb) ptype f > type = int * @__seg_fs > (gdb) ptype g > type = int * @__seg_gs > (gdb) info loc > f = 0x7ffff7fd9710 > g = 0x10 > > It seems to me that the "real" value of both f and g are 0x10. Instead, we > display the converted value, displaying f with a surprising value. Yes, that's another problem. GDB currently always does a pointer-to-address conversion, both if it then wants to use the address for accessing memory, and when it simply wants to *print* the pointer value. In the latter case, the address is printed via paddress. Again, I worked around this issue on the SPU using a hack: paddress always truncates the output to the size of an address on the platform, which I defined a 32 on the SPU. The extra bits to encode the SPU ID within a GDB address are placed in the high 32 bits, which means a sequence of pointer-to-address conversion followed by paddress actually prints the original *pointer* value. To clean this up, it seems GDB code should be clearer in when to use *GDB address* values (e.g. to access memory), and when to use *target pointer* values (e.g. for printing). This probably means auditing a lot of code ... > It seems to me that it would be better to do the conversion when we want to > dereference, such as "print *f", but not otherwise. However, I'm not really > sure how that would interact with the other users of address classes throughout > gdb. That might a workaround for the x86 case. I'd still encode address classes into the types, but leave pointer-to-address / address-to-pointer conversion as no-ops, and instead modify e.g. value_ind (pointer indirection). There is even already a callback to support type-specific value_ind implementations. However, I'm not completely sure this will cover all relevant cases where you really want an address. What about "x/x f", for example? Perhaps the correct place to hook is value_as_address? This already handles the gdbarch_integer_to_address callback today ... Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com