From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19707 invoked by alias); 8 Apr 2010 21:27:48 -0000 Received: (qmail 19693 invoked by uid 22791); 8 Apr 2010 21:27:47 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 08 Apr 2010 21:27:42 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o38LRIIo027033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Apr 2010 17:27:19 -0400 Received: from localhost.localdomain (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o38LRGCc014848; Thu, 8 Apr 2010 17:27:16 -0400 Message-ID: <4BBE4A34.3020301@redhat.com> Date: Thu, 08 Apr 2010 21:27:00 -0000 From: Phil Muldoon User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.3 MIME-Version: 1.0 To: Tom Tromey CC: Joel Brobecker , gdb-patches ml , Eli Zaretskii Subject: Re: [patch][python] Add breakpoint support. References: <4BB0B063.6000600@redhat.com> <20100405162648.GD19194@adacore.com> <4BBB3AF6.8050407@redhat.com> <4BBDCF0E.9020904@redhat.com> <20100408152905.GK19194@adacore.com> <4BBE32FF.8090508@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 2010-04/txt/msg00193.txt.bz2 On 04/08/2010 09:40 PM, Tom Tromey wrote: >>>>>> "Phil" == Phil Muldoon writes: > > Phil> There is a save_breakpoints.py script in the archer repository > Phil> already, so a lot of the work is done. I have a patch to modify that > Phil> to save watchpoints too. I've not ported it here today as I purely > Phil> want to concentrate on the API aspect of porting. But there is really > Phil> no reason why it can't go in immediately as part of another porting > Phil> effort. I think it would need some make/configure hackery to install, > Phil> which is definitely my weakest area. > > I can help with that if you want. That would be great, thanks. I'll check the Python breakpoint API in tomorrow at some point during BST time. So after that, it should be ok. > I think the more difficult problem is deciding how users should activate > commands written in Python. Right now for Archer we have this "require" > thing, but that seems like kind of a hack. OTOH, loading all the > commands at startup also seems weird. It will make startup slower, for > one thing. Maybe we could implement some kind of auto-loading? I normally (I think -- it's been awhile) just end up loading these with execfile in my .gdbinit. I cannot remember now. Anyway, it is not optimal. Off the cuff, I think some kind of lazy-loading script mechanism would be neat. Scripts would register interest (much like the the pretty-printers do now) in some kind of registry. I guess at start-up GDB would have to invoke at least script stubs. This would be so completion could work with Python scripts that are present but not loaded. And then, if all internal GDB commands are exhausted on completion, GDB could look in the Python script registry for commands and complete/load them on demand. Or something like that? I've no idea how difficult this lazy mechanism would be off-hand. Making GDB aware of all Python utility scripts in a library seems nebulous. How? Cheers, Phil