From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84354 invoked by alias); 17 Mar 2015 18:12:57 -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 84339 invoked by uid 89); 17 Mar 2015 18:12:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e06smtp12.uk.ibm.com Received: from e06smtp12.uk.ibm.com (HELO e06smtp12.uk.ibm.com) (195.75.94.108) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 17 Mar 2015 18:12:55 +0000 Received: from /spool/local by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 17 Mar 2015 18:12:51 -0000 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp12.uk.ibm.com (192.168.101.142) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 17 Mar 2015 18:12:49 -0000 Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 7A52B219005C for ; Tue, 17 Mar 2015 18:12:39 +0000 (GMT) Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2HICndu3539246 for ; Tue, 17 Mar 2015 18:12:49 GMT Received: from d06av02.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t2HIChLe031124 for ; Tue, 17 Mar 2015 12:12:48 -0600 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with SMTP id t2HICbPn030976; Tue, 17 Mar 2015 12:12:38 -0600 Message-Id: <201503171812.t2HICbPn030976@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 17 Mar 2015 19:12:37 +0100 Subject: Re: [PATCH 1/2] Fast tracepoint for powerpc64le To: palves@redhat.com (Pedro Alves) Date: Tue, 17 Mar 2015 18:12:00 -0000 From: "Ulrich Weigand" Cc: cole945@gmail.com (Wei-cheng Wang), gdb-patches@sourceware.org In-Reply-To: <54F73D41.9020109@redhat.com> from "Pedro Alves" at Mar 04, 2015 05:13:37 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15031718-0009-0000-0000-000003830ECC X-SW-Source: 2015-03/txt/msg00496.txt.bz2 Pedro Alves wrote: > On 02/27/2015 07:52 PM, Ulrich Weigand wrote: > > So I guess there's two ways to fix this. One would be to change > > gdbserver to work more like GDB here. This would involve removing > > the descriptor->code address conversion in remote.c, and instead > > performing the conversion in gdbserver's thread_db_enable_reporting. > > Now, there is no gdbarch_convert_from_func_ptr_addr in gdbserver, > > so a similar mechanism would have to be invented there. (I guess > > this would mean a new target hook.) Fortunately, the only platform > > that uses function descriptors *and* supports libthread_db debugging > > in gdbserver is ppc64-linux, so we'd only have to add that new > > mechanim on this platform. > > Note sure about this one, ppc64_convert_from_func_ptr_addr wants to > get at the bfd/binary's unrelocated sections. We'd have to teach > gdbserver to read the binary. That's probably not necessary. The reason the GDB implementation does it that way is that it needs to work under various different circumstances, like when debugging a core file, or before the dynamic linker has relocated an executable. For the gdbserver implementation, we should never need to handle such conditions, so we are able to simply read the target address from memory. > (Note for testing: __nptl_create_event will only be used > on old kernels without PTRACE_EVENT_CLONE, unless you hack the > code to force usage.) I wonder why Wei-cheng noticed the problem then ... Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com