From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8820 invoked by alias); 18 Mar 2015 11:04: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 8751 invoked by uid 89); 18 Mar 2015 11:04:59 -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: e06smtp13.uk.ibm.com Received: from e06smtp13.uk.ibm.com (HELO e06smtp13.uk.ibm.com) (195.75.94.109) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 18 Mar 2015 11:04:57 +0000 Received: from /spool/local by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 18 Mar 2015 11:04:53 -0000 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp13.uk.ibm.com (192.168.101.143) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 18 Mar 2015 11:04:50 -0000 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 6E8A51B0806B for ; Wed, 18 Mar 2015 11:05:13 +0000 (GMT) Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2IB4oFD8126824 for ; Wed, 18 Mar 2015 11:04:50 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 t2IB4g3o004567 for ; Wed, 18 Mar 2015 05:04: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 t2IB4bne004457; Wed, 18 Mar 2015 05:04:38 -0600 Message-Id: <201503181104.t2IB4bne004457@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 18 Mar 2015 12:04:37 +0100 Subject: Re: [PATCH 1/2] Fast tracepoint for powerpc64le To: palves@redhat.com (Pedro Alves) Date: Wed, 18 Mar 2015 11:04:00 -0000 From: "Ulrich Weigand" Cc: cole945@gmail.com (Wei-cheng Wang), gdb-patches@sourceware.org In-Reply-To: <55087A67.1070403@redhat.com> from "Pedro Alves" at Mar 17, 2015 07:03:03 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: 15031811-0013-0000-0000-00000359974B X-SW-Source: 2015-03/txt/msg00540.txt.bz2 Pedro Alves wrote: > On 03/17/2015 06:12 PM, Ulrich Weigand wrote: > > 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. > > > > Maybe not cores today, but why doesn't gdbserver have to > handle the case of connecting before the executable has been > relocated? > > I also wonder about all the break-interp.exp corner cases. gdbserver would access function descriptors only for the __nptl_create_event etc. routines. These are looked up only after a libthread_db td_ta_new_p call succeeds, which should only be true if libpthread has been loaded (and relocated) in the inferior. If it hasn't been yet at the time gdbserver attaches, the whole thread initialization sequence is defered until after the new_objfile event that happens after libpthread *was* loaded and relocated. Am I missing something here? Maybe if in the future additional function descriptor lookups are added to gdbserver, we could run into that issue. In any case, the other solution is probably better anyway. > >> (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 ... > > I think he is seeing the problem with the function symbol look ups > gdbserver's tracepoints module does (tracepoint_look_up_symbols), > and that in that case he needs to get the function descriptor > instead of the start of code address? From your previous explanation > I understand that the __nptl_create_event breakpoint (when used) > is set correctly because what gdbserver needs in that case is the start > of code address, which is what remote.c returns. Ah, of course. Sorry for the confusion. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com