From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12414 invoked by alias); 8 Dec 2011 15:33:58 -0000 Received: (qmail 12403 invoked by uid 22791); 8 Dec 2011 15:33:56 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_BP X-Spam-Check-By: sourceware.org Received: from mail-vx0-f169.google.com (HELO mail-vx0-f169.google.com) (209.85.220.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 08 Dec 2011 15:33:43 +0000 Received: by vcbfk26 with SMTP id fk26so1769119vcb.0 for ; Thu, 08 Dec 2011 07:33:42 -0800 (PST) Received: by 10.52.94.75 with SMTP id da11mr1864051vdb.111.1323358422242; Thu, 08 Dec 2011 07:33:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.4.210 with HTTP; Thu, 8 Dec 2011 07:33:21 -0800 (PST) In-Reply-To: References: From: Kevin Pouget Date: Thu, 08 Dec 2011 16:10:00 -0000 Message-ID: Subject: Re: [RFC] Python Finish Breakpoints To: Tom Tromey Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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 X-SW-Source: 2011-12/txt/msg00269.txt.bz2 On Thu, Dec 8, 2011 at 3:56 PM, Tom Tromey wrote: >>>>>> "Kevin" =3D=3D Kevin Pouget writes: > > Kevin> and we're .... not ready! > Kevin> there are some regressions this morning, certainly due to your > Kevin> ambiguous linespec patch! > > Kevin> first one is quite obvious: > > Kevin> a/gdb/testsuite/gdb.python/py-finish-breakpoint.exp > Kevin> -if ![runto "getpid"] then { > Kevin> - =A0 =A0fail "Cannot run to getpid." > Kevin> +if ![runto_main] then { > Kevin> + =A0 =A0fail "Cannot run to main." =A0 =A0 return 0 } > Kevin> +gdb_breakpoint "getpid" {temporary} > Kevin> +gdb_test "continue" "Temporary breakpoint .*in getpid.*" "continu= e to getpid" > Kevin> + > > Kevin> "break getpid" used to work before actually starting the inferior,= but > Kevin> now it's unresolved > > This test assumes that there is no debuginfo for getpid -- but in my > case, I have glibc debuginfo installed. =A0This isn't unheard of for gdb > developers :) > > The test would be more robust if you put a new function in a new file > and arranged for that file to be compiled without debuginfo. > > Sorry I didn't notice this before. I'll work on that, thanks for noticing it > Kevin> bpfinishpy_out_of_scope can't be triggered anymore because you set > Kevin> b-> pspace to NULL. I hesitated about how to fix it, but I think t= hat > Kevin> FinishBP have to be bound to the pspace in which they were set, so= I > Kevin> added this line: > > It seems to me that one of these breakpoints has to be thread-specific > as well. =A0Maybe the code to set b->pspace should notice thread-specific > breakpoints and allow pspace to be set there. > > I'd rather this be done in breakpoint.c than have other modules modify > struct breakpoint directly. > > Tom you're right about thread-specific, but I'm not sure how to enforce it. Currently, FinishBreakpoint only accepts a frame as parameter, and a frame is only bound to a pspace, not a thread ... My code > self_bpfinish->py_bp.bp->pspace =3D current_program_space; was wrong, it should rather be > pspace =3D get_frame_program_space (prev_frame); and this also implies that we can't really defer this setting to another place ... Maybe we can state in the documentation that FinishBreakpoint will be created by default in the selected thread, and add another parameter in the constructor to specify another thread?