From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14082 invoked by alias); 21 Oct 2011 07:46:24 -0000 Received: (qmail 14069 invoked by uid 22791); 21 Oct 2011 07:46:22 -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_BJ 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; Fri, 21 Oct 2011 07:46:07 +0000 Received: by vcbfk1 with SMTP id fk1so4092876vcb.0 for ; Fri, 21 Oct 2011 00:46:06 -0700 (PDT) Received: by 10.220.213.132 with SMTP id gw4mr1031658vcb.52.1319183166305; Fri, 21 Oct 2011 00:46:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.180.75 with HTTP; Fri, 21 Oct 2011 00:45:46 -0700 (PDT) In-Reply-To: References: From: Kevin Pouget Date: Fri, 21 Oct 2011 08:15: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-10/txt/msg00586.txt.bz2 On Thu, Oct 20, 2011 at 10:41 PM, Tom Tromey wrote: >>>>>> "Kevin" =3D=3D Kevin Pouget writes: > > Tom> You need to store a gdb.Type wrapper. > Tom> A 'struct type' can also be invalidated when an objfile is destroyed. > > Kevin> I wouldn't mind, but I can't see how gdb.Type ensures validity, as= far > Kevin> as I've seen, there is no "is_valid" method and I can't and no fur= ther > Kevin> verification during the Python -> C translation: > > When an objfile is destroyed, py-type.c:save_objfile_types is called. > This makes a copy of the struct type underlying any relevant Type object. I'll take a look at that, I don't remember what was the problem! > [ out_of_scope_notif ] > Kevin> - avoid calling `out_of_scope' every normal_stop when the breakpoi= nt > Kevin> is not anymore in the callstack > > It seems to me that manually managing this is not the best we could do. > > I was re-reading the code and I realized that this isn't actually > working the way I had remembered it working: > > +A @fdb{finish breakpoint} is a breakpoint set at the return address of > +a frame, based on the "finish command. @code{gdb.FinishBreakpoint} exten= ds > +@code{gdb.Breakpoint} > > This approach is fine; but once a frame is gone, it is gone -- we should > just destroy the breakpoint at that point. =A0Maybe this would make the > internal logic simpler as well. yes, I think you're right with that, "once a frame is gone, it is gone", I actually don't use myself this 'permanent finish breakpoint' feature, so I'll change it. So basically, the BP must be deleted right after it has been it (maybe through the 'temporary' mechanism). 'out_of_scope' will be triggered in the same conditions as before, but instead of playing with 'out_of_scope_notif' I'll delete the GDB breakpoint (thus invalidating the Python BP) I'll post a patch going this way later today > (I had been laboring under the misconception that a finish breakpoint > took a linespec and then did the bookkeeping of "note function entry / > set a new breakpoint" -- but actually I like your simpler approach > better, and the latter can be done more easily purely in Python.) I'm not sure to understand exactly what you had in mind, but if you prefer my solution that's okay Thanks, Kevin