From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13369 invoked by alias); 10 Nov 2014 17:16:46 -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 13355 invoked by uid 89); 10 Nov 2014 17:16:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: e31.co.us.ibm.com Received: from e31.co.us.ibm.com (HELO e31.co.us.ibm.com) (32.97.110.149) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 10 Nov 2014 17:16:45 +0000 Received: from /spool/local by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 10 Nov 2014 10:16:43 -0700 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e31.co.us.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 10 Nov 2014 10:16:41 -0700 Received: from b03cxnp07029.gho.boulder.ibm.com (b03cxnp07029.gho.boulder.ibm.com [9.17.130.16]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id BF7571FF003D for ; Mon, 10 Nov 2014 10:05:25 -0700 (MST) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by b03cxnp07029.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id sAAFCC2g66322500 for ; Mon, 10 Nov 2014 16:12:12 +0100 Received: from d03av02.boulder.ibm.com (localhost [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id sAAHFaUc022968 for ; Mon, 10 Nov 2014 10:15:37 -0700 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d03av02.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with SMTP id sAAHFXg1022508; Mon, 10 Nov 2014 10:15:34 -0700 Message-Id: <201411101715.sAAHFXg1022508@d03av02.boulder.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 10 Nov 2014 18:15:33 +0100 Subject: Re: [PATCH] create_internal_breakpoint: Apply gdbarch_skip_entrypoint. To: palves@redhat.com (Pedro Alves) Date: Mon, 10 Nov 2014 17:16:00 -0000 From: "Ulrich Weigand" Cc: dje@google.com (Doug Evans), gdb-patches@sourceware.org In-Reply-To: <5460DDA4.1010107@redhat.com> from "Pedro Alves" at Nov 10, 2014 03:45:40 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: 14111017-8236-0000-0000-000006CE9D4C X-SW-Source: 2014-11/txt/msg00169.txt.bz2 Pedro Alves wrote: > Hmm, not sure. Are there cases that do want a breakpoint > on the specific address that was passed down, even if it was > the entry point address? I'm looking at the watchpoint scope > code: > > scope_breakpoint > = create_internal_breakpoint (frame_unwind_caller_arch (frame), > frame_unwind_caller_pc (frame), > bp_watchpoint_scope, > &momentary_breakpoint_ops); > > and wondering about a signal coming in just while the mainline code > was going to execute the entry point address. Hmm, OK. It probably wouldn't matter in practice, but I agree that in principle, this usage should not skip to the local entry point. > I'm particularly thinking of gdbarch_convert_from_func_ptr_addr, and > wondering why create_overlay_event_breakpoint doesn't need to call it. > The jit event breakpoint code doesn't call it either, it seems. > And neither the longjmp even breakpoint, when the breakpoint > it set by function name instead of by probe. Are these just cases > of people not having stumbled on this yet? Or are these event > locations/functions different somehow? Why does the solib-svr4.c > need to call gdbarch_convert_from_func_ptr_addr for its event > functions, while others do not? gdbarch_convert_from_func_ptr_addr pretty much was added whereever someone noticed that something didn't work on ppc64 ... In particular, on Linux/ppc64 we don't use overlays; JIT didn't work for other reasons anyway, same for non-probe longjmp. The non-svr4 solib routines aren't used on ppc64. I agree it would be better to clean this up somehow. > (or instead move the gdbarch calls to a helper function that given > an address, returns the function's breakpoint address?) This sounds reasonable. Maybe start with an msymbol instead of an address to make sure this is used only where we have symbol address to start with? This is what most users of create_internal_breakpoint acually do anyway. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com