From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14913 invoked by alias); 15 Jul 2004 20:04:27 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 14864 invoked from network); 15 Jul 2004 20:04:24 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org with SMTP; 15 Jul 2004 20:04:24 -0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i6FK4hh8027596 for ; Thu, 15 Jul 2004 13:04:43 -0700 (PDT) Received: from relay2.apple.com (relay2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Thu, 15 Jul 2004 13:04:23 -0700 Received: from [17.201.22.21] (moleja.apple.com [17.201.22.21]) by relay2.apple.com (8.12.11/8.12.11) with ESMTP id i6FK4LwQ020494; Thu, 15 Jul 2004 13:04:21 -0700 (PDT) In-Reply-To: <16630.57035.572672.532135@nick.uklinux.net> References: <40DE2D1B.4070003@gnu.org> <200406302047.QAA29956@smtp.ott.qnx.com> <16613.39781.921538.192414@nick.uklinux.net> <40EDC76F.2070809@gnu.org> <16625.46597.86962.340302@nick.uklinux.net> <40F2986D.4010205@gnu.org> <16626.56338.385281.264806@nick.uklinux.net> <40F697E7.9060904@gnu.org> <16630.57035.572672.532135@nick.uklinux.net> Mime-Version: 1.0 (Apple Message framework v669) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <28ADB7D6-D69A-11D8-BBF3-000A9569836A@apple.com> Cc: Andrew Cagney , Alain Magloire , gdb@sources.redhat.com Content-Transfer-Encoding: 7bit From: Jason Molenda Subject: Re: How does GDB/MI give the current frame Date: Thu, 15 Jul 2004 20:19:00 -0000 To: Nick Roberts X-SW-Source: 2004-07/txt/msg00185.txt.bz2 On Jul 15, 2004, at 12:45 PM, Nick Roberts wrote: >> That's almost the whole idea. The -interpreter-exec command provides >> two mechanism to the GUI/client: >> >> - the ability to access GDB's `console' vis: >> -> -interpreter cli "up" >> <- ~"info on new frame..." >> <- done >> >> - the ability to notify the GUI of console sideeffects vis: >> <- *select-frame,... > > That sounds like a third interface. This is an elegant approach but > assumes > that someone will implement the notification for every CLI command > that has > side effects. This seems unlikely in the current circumstances For what it's worth, at Apple we've done what Andrew is proposing. Our method spits out a "MI_HOOK_RESULT" notification on the ^done result whenever the console command entered by the user has changed the state in an important way. e.g. (gdb) -interpreter-exec console-quoted up ~"#2 0x000321f4 in gdb_main (args=0xbffff620) at ../../gdb/src/gdb/main.c:851\n" ~"851\t catch_errors (captured_main, args, \"\", RETURN_MASK_ALL);\n" ^done,MI_HOOK_RESULT=[HOOK_TYPE="frame_changed",frame="2"],time= {wallclock="0.00620",user="0.00323",system="0.00283",start="1089921236.3 59009",end="1089921236.365212"} (gdb) (Ignore the "console-quoted" -- we have a separate interpreter for console output marshalled through the MI quoting rules) (and ignore the time= thing at the end; that's a little internal debug thing we use to track down performance problems more easily between gdb an the UI. Our UI has a feature where it saves all MI text to a file for debugging; it's *invaluable* for tracking down bugs and our UI timestamps its own logging messages so we can tell whether the UI or gdb is being slow when we get reports of slowness.) FWIW, here's the list of notification hooks we currently generate: breakpoint_create, breakpoint_modify, breakpoint_delete, stack_changed, frame_changed, thread_changed. J