From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 964 invoked by alias); 3 Jul 2015 16:42:19 -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 955 invoked by uid 89); 3 Jul 2015 16:42:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: e06smtp14.uk.ibm.com Received: from e06smtp14.uk.ibm.com (HELO e06smtp14.uk.ibm.com) (195.75.94.110) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Fri, 03 Jul 2015 16:42:17 +0000 Received: from /spool/local by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 3 Jul 2015 17:42:14 +0100 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp14.uk.ibm.com (192.168.101.144) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 3 Jul 2015 17:42:13 +0100 X-MailFrom: uweigand@de.ibm.com X-RcptTo: gdb-patches@sourceware.org Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id EECBC1B08061 for ; Fri, 3 Jul 2015 17:43:21 +0100 (BST) Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t63GgCAu29753430 for ; Fri, 3 Jul 2015 16:42:12 GMT Received: from d06av04.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t63GgB8d021608 for ; Fri, 3 Jul 2015 10:42:12 -0600 Received: from oc7340732750.ibm.com (icon-9-164-134-232.megacenter.de.ibm.com [9.164.134.232]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id t63GgBtB021602; Fri, 3 Jul 2015 10:42:11 -0600 Received: by oc7340732750.ibm.com (Postfix, from userid 500) id B90145BFD; Fri, 3 Jul 2015 18:42:10 +0200 (CEST) Subject: Re: [PATCH 2/7 v3] Tracepoint for ppc64. To: cole945@gmail.com (Wei-cheng Wang) Date: Fri, 03 Jul 2015 16:42:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: from "Wei-cheng Wang" at Jun 28, 2015 01:48:36 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20150703164210.B90145BFD@oc7340732750.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15070316-0017-0000-0000-0000049E0FDB X-SW-Source: 2015-07/txt/msg00101.txt.bz2 Wei-cheng Wang wrote: > On Thu, Apr 9, 2015 at 12:57 AM, Ulrich Weigand wrote: > > Wei-cheng Wang wrote: > >> The fail cases in gdb-unavailable are caused by inaccessible vtable for object > >> For x86, such structures (_ZVTxxx) are put in .rodata section, so gdb can read > >> them in local file if not collected by tracepoint action, but for PowerpPC, > >> they are put in .rel.ro sections. Technically they not read-only, so gdb won't > >> read them in file if not collected. > > > > Is this really a difference between Intel and PowerPC, or this is rather > > a difference between different binutils levels? I don't see off-hand > > why this should be Power-specific ... Do you have example assembler > > code that shows the difference? Ah, I think I see. The difference is that on PowerPC, *all* code (even in the main executable) is built as position-independent. For PIC code, the vtable must be relocated and hence reside in a .data.rel.ro section; while for non-PIC code the vtable can be in .rodata. So the same problem would probably appear on Intel as well if we build the testcase as PIC or PIE. > In this case, gdb wants to access (vtable for Derived + 32). > Because it's not collected, gdb tries to see if the address is read-only, > so it can access it from files. See also remote_xfer_live_readonly_partial. Hmm. I guess we could try to add support for using .data.rel.ro sections from the executable file as well; the contents would have to be relocated by GDB, but there's already support to do that in other cases ... Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com