From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32324 invoked by alias); 23 Jun 2008 17:35:03 -0000 Received: (qmail 32295 invoked by uid 22791); 23 Jun 2008 17:35:02 -0000 X-Spam-Check-By: sourceware.org Received: from mail-out3.apple.com (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 23 Jun 2008 17:34:41 +0000 Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id A4A763041018; Mon, 23 Jun 2008 10:34:40 -0700 (PDT) Received: from relay14.apple.com (unknown [127.0.0.1]) by relay14.apple.com (Symantec Mail Security) with ESMTP id 884902808A; Mon, 23 Jun 2008 10:34:40 -0700 (PDT) X-AuditID: 11807134-aaa02bb000000ece-c8-485fdeb02111 Received: from [17.201.22.244] (gdbrulez.apple.com [17.201.22.244]) by relay14.apple.com (Apple SCV relay) with ESMTP id 674502808C; Mon, 23 Jun 2008 10:34:40 -0700 (PDT) In-Reply-To: References: <20080619190942.GA3744@adacore.com> <18526.15596.855756.886158@kahikatea.snap.net.nz> From: Jim Ingham X-Mailer: Apple Mail (2.1018.1) Mime-Version: 1.0 (Apple Message framework v1018.1) To: tromey@redhat.com Content-Type: text/plain; delsp=yes; charset=us-ascii; format=flowed Message-Id: Date: Mon, 23 Jun 2008 17:35:00 -0000 Content-Transfer-Encoding: 7bit Cc: gdb@sourceware.org Subject: Re: GDB Focus Group at the 2008 GCC Summit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-06/txt/msg00220.txt.bz2 The actual mechanism was not that hard to work from the gdb side, you just need the fix bundle and what it is replacing. The part the IDE was most useful for was coordinating building the new fix bundle appropriately, and remembering what it was replacing. From what I remember, there were two things that were a real pain (though Jason can tell in more detail...) One was the part where you try to validate that the change you are about to make is safe (for instance you aren't changing the size of a structure, etc...) You don't need to do this, but it seems really unfriendly to let people do stuff that you know is going to cause their program to crash, so we felt it was a necessary part of a complete implementation. This is not particularly hard, but it is tedious. There's a bunch of that in our version that might be useful. The other really painful part is figuring out how to play nice with the various runtimes that you're adding methods into. I don't remember all the details, but we had to add hacks to both the C++ and the ObjC runtimes to make them like doing surgery on classes on the fly. That's hard because you have to coordinate it with the system runtime libraries. It was also the most fragile part. We still have some people who use fix and continue but IMHO it was never really worth the effort, given how fragile it ended up being. Jim On Jun 23, 2008, at 8:17 AM, Tom Tromey wrote: >>>>>> "Nick" == Nick Roberts writes: > >>> | * Fix and continue: >>> | >>> | Perhaps try to implement this feature through the use of >>> Python. >>> | For instance, use python to build a return value, and return >>> that. > > Nick> Apple GDB already has fix and continue. Couldn't that be used > Nick> as a reference implementaton? > > I didn't take notes on this, but apparently fix-and-continue is kind > of a pain to implement, and AFAICS needs IDE integration to work > properly anyhow. The Python idea is more of a cute hack than a really > serious thing. > > Tom